<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Il 27/10/2010 10:24, Cristiano Belloni ha scritto:
<blockquote cite="mid:4CC7E1C0.4040904@imavis.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Il 27/10/2010 10:01, Ross Finlayson ha scritto:
<blockquote cite="mid:f06240800c8ed8cb10041@%5B66.80.62.44%5D"
type="cite">
<blockquote type="cite">I did something similar, Francisco. In a
nutshell, you've got to extend JPEGVideoSource and look for
DRI markers like this: <br>
</blockquote>
<br>
Feel free to post a patch file, and I'll look at folding these
changes into a future release. <br>
</blockquote>
As soon as I'm done with the "double free" issue (I'm
investigating!), I'll gladly post a patch for MJPEG!<br>
<br>
Thanks & Regards,<br>
Cristiano.<br>
<br>
<div class="moz-signature">-- <br>
Belloni Cristiano<br>
Imavis Srl.<br>
<a moz-do-not-send="true" href="http://www.imavis.com">www.imavis.com</a><br>
<a moz-do-not-send="true" href="mailto://belloni@imavis.com">belloni@imavis.com</a><br>
</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
live-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
</blockquote>
Dear Ross,<br>
As I suspected, my modifications to make live555 support the MJPEG
restart markers was the cause of the double-free issue.<br>
In this mail, I attach my JPEGRSTVideoRTPSink class, that extends
VideoRTPSink, and LiveJPEGStreamSource, that extends JPEGVideoSource
to parse JPEG.<br>
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.<br>
<br>
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.<br>
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:<br>
<br>
if (fOutBuf->haveOverflowData()<br>
&& fOutBuf->totalBytesAvailable() >
fOutBuf->totalBufferSize()/2) {<br>
// Efficiency hack: Reset the packet start pointer to just in
front of<br>
// the overflow data (allowing for the RTP header and special
headers),<br>
// so that we probably don't have to "memmove()" the overflow
data<br>
// into place when building the next packet:<br>
unsigned newPacketStart = fOutBuf->curPacketSize()<br>
- (rtpHeaderSize + fSpecialHeaderSize +
frameSpecificHeaderSize());<br>
fOutBuf->adjustPacketStart(newPacketStart);<br>
}<br>
<br>
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.<br>
<br>
Solution: commenting out the efficiency hack seems to make the whole
thing work.<br>
<br>
[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.]<br>
<br>
Best Regards,<br>
Cristiano.<br>
<br>
<div class="moz-signature">-- <br>
Belloni Cristiano<br>
Imavis Srl.<br>
<a href="http://www.imavis.com">www.imavis.com</a><br>
<a href="mailto://belloni@imavis.com">belloni@imavis.com</a><br>
</div>
</body>
</html>