<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thank you Matt and Ross.<br>
<br>
My code is already calling <i>increaseReceiveBufferTo(2000000)</i> for
the video and <i>100000</i> for the audio. I added a call to <i>increaseSendBufferTo(20000000)</i>
on the server side but it didn't make a difference.<br>
<br>
My preliminary investigation tells me that I'm receiving all the
packets (I added TRACEs in <i>MultiFramedRTPSource::networkReadHandler</i>).
I will look into <i>MultiFramedRTPSource::doGetNextFrame1</i>.<br>
<br>
See below.<br>
<br>
Matt Schuckmann wrote:
<blockquote cite="mid:49C2B75C.3080809@schuckmannacres.com" type="cite">Chances
are your socket receiver buffers in the OS are too small.
<br>
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.
<br>
<br>
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.
<br>
<blockquote type="cite"><br>
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.
<br>
</blockquote>
I'd be interested to know if this works because I got the impression
that it doesn't.</blockquote>
It seems to be working. I modified unsigned OutPacketBuffer::maxSize =
600000 instead of 60000. But it works with the smaller value. <br>
<blockquote cite="mid:49C2B75C.3080809@schuckmannacres.com" type="cite"><br>
<br>
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.
<br>
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.
<br>
<br>
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.
<br>
</blockquote>
I currently can't configure it to encode multiple slices which is a
pain since my S/W decoder is multi-threaded.<br>
<br>
Regards,<br>
<br>
Georges<br>
<blockquote cite="mid:49C2B75C.3080809@schuckmannacres.com" type="cite"><br>
Matt S.
<br>
iMove Inc.
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mschuck@imoveinc.com">mschuck@imoveinc.com</a>
<br>
_______________________________________________
<br>
live-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
<br>
<br>
</blockquote>
</body>
</html>