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.
[email protected]
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
|
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
