[Live-devel] JPEGVideoRTPSink and Restart markers

[Cristiano Belloni]

Il 02/11/2010 14:07, Ross Finlayson ha scritto:
>> Ross, thanks for the new release. I have tried it and is not working 
>> here.
>
> Please let me know if you find any bugs in the latest release, because 
> it is the only version for which support will be given. (Remember, You 
> Have Complete Source Code.)
Dear Ross,
I seem to experience the very same double-free corruption problem I 
already reported with the latest version of your code (live.2010.11.04), 
streaming mjpeg on rtp.

For convenience, I report the problem again here:

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 (but the CPU toll without the efficiency hack is too high).

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/20101110/0be556fa/attachment.html>