<!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 02/11/2010 14:07, Ross Finlayson ha scritto:
<blockquote cite="mid:f06240803c8f5bd07161a@%5B66.80.62.44%5D"
type="cite">
<blockquote type="cite">Ross, thanks for the new release. I have
tried it and is not working here.
<br>
</blockquote>
<br>
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.)
<br>
</blockquote>
Dear Ross,<br>
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.<br>
<br>
For convenience, I report the problem again here:<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 (but the CPU toll without the efficiency hack is too
high).<br>
<br>
Regards,<br>
Cristiano.<br>
<br>
<div class="moz-signature">-- <br>
<title></title>
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>