[Live-devel] JPEGVideoRTPSink and Restart markers + My Implementation

[Cristiano Belloni]

  Il 27/10/2010 10:24, Cristiano Belloni ha scritto:
> Il 27/10/2010 10:01, Ross Finlayson ha scritto:
>>> I did something similar, Francisco. In a nutshell, you've got to 
>>> extend JPEGVideoSource and look for DRI markers like this:
>>
>> Feel free to post a patch file, and I'll look at folding these 
>> changes into a future release.
> As soon as I'm done with the "double free" issue (I'm investigating!), 
> I'll gladly post a patch for MJPEG!
>
> Thanks & Regards,
> Cristiano.
>
> -- 
> Belloni Cristiano
> Imavis Srl.
> www.imavis.com <http://www.imavis.com>
> belloni at imavis.com <mailto://belloni@imavis.com>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
Dear Ross,
As I suspected, my modifications to make live555 support the MJPEG 
restart markers was the cause of the double-free issue.
In this mail, I attach my JPEGRSTVideoRTPSink class, that extends 
VideoRTPSink, and LiveJPEGStreamSource, that extends JPEGVideoSource to 
parse JPEG.
Please note I didn't modify anything in liveMedia, but only extended its 
classes, instead. That's why I attached the entire JPEGRSTVideoRTPSink 
implementation, and not a patch to your JPEGVideoRTPSink.

The double-alloc issue seems to be triggered when I add a 4-byte special 
header for the RestartMarkerHeader in JPEGRSTVideoRTPSink class. This 
calls setSpecialHeaderBytes(), that calls OutPacketBuffer::insert(). In 
JPEGRSTVideoRTPSink::specialHeaderSize, I also set headerSize += 4 at 
the end, assuming that restart markers are present.
So far so good, but, investigating, I found that, somehow, this breaks 
MultiFramedRTPSink. In particular, this seems to invalidate the 
assumptions made in this piece of code:

if (fOutBuf->haveOverflowData()
&& fOutBuf->totalBytesAvailable() > fOutBuf->totalBufferSize()/2) {
     // Efficiency hack: Reset the packet start pointer to just in front of
     // the overflow data (allowing for the RTP header and special headers),
     // so that we probably don't have to "memmove()" the overflow data
     // into place when building the next packet:
       unsigned newPacketStart = fOutBuf->curPacketSize()
       - (rtpHeaderSize + fSpecialHeaderSize + frameSpecificHeaderSize());
       fOutBuf->adjustPacketStart(newPacketStart);
    }

The first time it's invoked, the efficiency hack sets newPacketStart to 
4294939175 (!), and fOutBuf is adjusted to this value. This corrupts the 
fOutBuf OutPacketBuffer. When the buffer is deleted, it tries to dealloc 
4 gigabytes, and glibc gets very angry.

Solution: commenting out the efficiency hack seems to make the whole 
thing work.

[One last note: I didn't understand very well why the hack does not 
work. Since I tested this on an ARM/Montavista platform, it might be an 
"architectural" issue, since the number is very close to 2^32. I mean, 
the problem might be that this hack works only on Intel PCs, but not on 
other architectures. But I'm absolutely not sure.]

Best Regards,
Cristiano.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JPEGRSTVideoRTPSink.cpp
Type: text/x-c++src
Size: 4925 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JPEGRSTVideoRTPSink.hh
Type: text/x-c++hdr
Size: 1946 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LiveJPEGStreamSource.cpp
Type: text/x-c++src
Size: 8655 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LiveJPEGStreamSource.h
Type: text/x-chdr
Size: 2627 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101027/c7b53228/attachment-0007.bin>