<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Thank you all for your help.<br>
<br>
It looks like the problem is on my side. One engineer, before he left,
started implementing Forward Error Correction and it looks like the new
code is causing the loss of packets. A modified<i>
ReorderingPacketBuffer::storePacket</i> was rejecting the incoming
packets when there were too many of them. I disabled all the FEC code
and it is much more stable. <br>
<br>
I apologize for any inconvenience this may have caused.<br>
<br>
As for very large buffers, it seems to work very well. I modified <i>currentNALUnitEndsAccessUnit
</i>to return <i>false </i>unless it is sending the last chunk of the
compressed frame. That was before I set the global variable <i>OutPacketBuffer::maxSize</i>
to a larger value.<br>
<br>
On the client side, the destination buffer is large enough to hold the
largest compressed frame.<br>
<br>
Georges<br>
<br>
Patrick White wrote:
<blockquote cite="mid:200903200856.57661.patbob@imoveinc.com"
type="cite">
<pre wrap="">I just fixed this issue in our code last night -- the I-frame from the H.264
encoder was getting truncated because it was too big to fit into the stock
OutPacketBuffer buffer (only ~60000 bytes).
The short answer is that the entire outgoing packet must fit into a buffer --
there's no way for the LIVE555 code to output the correct packets if it
doesn't. Matt's idea of having the codec produce smaller NALs has a good
channe of working.. but I just upped the buffers for now:
On the server end, before you instantiate RTSPServer, set the global variable
OutPacketBuffer::maxSize to your desired output buffer size. The output
buffer(s) will be automatically allocated. On the client side you have to
call getNextFrame() with a big enough buffer -- that call happens from code
we've written, so I don't know what you might have to do to make it work, or
even if you need to do anything.
I upped both buffers because I'm in a hurry -- perhaps only the outgoing
buffer is sufficient.
Long answer: Over in H264FUAFragmenter::doGetNextFrame(), it uses case 2 to
send the initial FU-A packet after it gets a new buffer full, then case 3 to
send the balance of that buffer via FU-B packets. Near as I can tell,
there's no way to jump back into case 3 with another buffer full.. ergo, the
entire frame must fit into a single buffer full to be sent out as the proper
sequence of FU-A/FU-B packets. At least, that's the state of the code as of
a month or two ago when we last updated... Ross, the code's a little
convoluted down there, is my interpretation correct?, did I misunderstand the
logic flow? or have you made recent changes down there to fix it?
Regardless, upping the buffer sizes fixed the issue for us.
Hope that helps.
patbob
On Thu Mar 19 12:56:08 2009, Georges Côté wrote:
</pre>
<blockquote type="cite">
<pre wrap="">..
I based my code on the H.264 tutorial.
I get corruption once in a while. The H/W encoder is configured to
generate one IDR and 14 forward frames, no backward frames (I, P and B
in mpeg2 terminology). I'm not sure of the H.264 terminology.
What I see is that the reference frames are quite large > 150 KB while
the other frames are around 15 KB.
Most of the times, the client is called with the right size. Once in a
while, I will be missing part of a IDR or even the whole reference
frame. If I use Wireshark on the client side, I see that I'm receiving
the "missing" packets. I haven't digged in the code to investigate yet!
On the server side, when the frame is larger than the destination
buffer, I copy as much as I can. The remaining data will be copied when
doGetNextFrame is called again.
Incomplete parts have the right presentation time but I set the duration
to 0.
The last part has the same presentation time but I set the duration
according to the right frame rate.
..
</pre>
</blockquote>
<pre wrap=""><!---->
On Friday 20 March 2009 6:48 am, Georges Côté wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Thank you Matt and Ross.
My code is already calling increaseReceiveBufferTo(2000000) for the video
and 100000 for the audio. I added a call to increaseSendBufferTo(20000000)
on the server side but it didn't make a difference.
My preliminary investigation tells me that I'm receiving all the packets
(I added TRACEs in MultiFramedRTPSource::networkReadHandler). I will look
into MultiFramedRTPSource::doGetNextFrame1.
See below.
Matt Schuckmann wrote:
Chances are your socket receiver buffers in the OS are too small.
Try increasing them with calls to setReceiveBufferTo() or
increaseReceiveBufferTo(), I think you can find examples of this in the
OpenRTSP example and I think there are some references to this in the FAQ.
Check out the FAQ because there maybe some registry/config settings (in the
case of windows) you need to change to allow bigger buffers.
There are companion methods for the send buffers on the server side but I
don't think your having a problem with that if WireShark shows all the data
is making it to the client.
On the server side, when the frame is larger than the destination buffer,
I copy as much as I can. The remaining data will be copied when
doGetNextFrame is called again.
I'd be interested to know if this works because I got the impression that
it doesn't. It seems to be working. I modified unsigned
OutPacketBuffer::maxSize = 600000 instead of 60000. But it works with the
smaller value.
There is a similar buffer on the client side that is used to pass data to
the afterGettingFrame() method of your videoSink, if the data is too big
for that buffer then the numTrucatedBytes parameter is set to number of
bytes that are lost and as far as I can tell that data is gone. I don't
think I've come across a case where this has occurred but in theory it
could happen, I'm still not sure how you'd increase this buffer size.
Another thing you might try is to have your H.264 encoder slice up the
frames into multiple slices, I think this will push your NAL packet sizes
down which should reduce the buffer size requirements. I haven't tired this
either but I've been meaning to just to see what happens.
I currently can't configure it to encode multiple slices which is a pain
since my S/W decoder is multi-threaded.
Regards,
Georges
Matt S.
iMove Inc.
<a class="moz-txt-link-abbreviated" href="mailto:mschuck@imoveinc.com">mschuck@imoveinc.com</a>
_______________________________________________
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>
<pre wrap=""><!---->_______________________________________________
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>
</body>
</html>