[Live-devel] A Problem of RTSP Server
Ross Finlayson
finlayson at live555.com
Sun Aug 12 21:50:58 PDT 2012
The problem with your file can be seen clearly if you look at the warning messages that are clearly being output on your console. For example:
MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too large for our buffer size (101348). 35198 bytes of trailing data was dropped! Correct this by increasing "OutPacketBuffer::maxSize" to at least 135198, *before* creating this 'RTPSink'. (Current value is 100000.)
(Did you not notice these messages in your console output??)
I.e., the problem is that your file contains several extremely large (I might say ridiculously large - see below[*]) NAL unit. By default, the "LIVE555 Media Server" code uses a buffer that is not large enough to handle such huge NAL units. However, you can fix it by changing line 117 of "mediaServer/DynamicRTSPServer.cpp" from
OutPacketBuffer::maxSize = 100000; // allow for some possibly large H.264 frames
to
OutPacketBuffer::maxSize = 200000; // allow for some possibly large H.264 frames
and recompiling the LIVE555 Media Server.
If you do this, you will eliminate the problem at the server end. However, your client - VLC - will still have a problem when it receives the first of these extremely large NAL units. It also uses a buffer that is, by default, too small to receive these large NAL units. The first time it notices that its buffer is too small, it will increase the buffer size, and then that will prevent the problem reoccurring for subsequent NAL units.
[*]The only way to overcome this (other than by modifying and recompiling VLC, but that's not our software) is to not send such ridiculously large NAL units. You should reconfigure your encoder to encode each IDR picture (i.e., 'I-frame') into multiple 'slice' NAL units. This is a good idea, because if packets forming a 'slice' NAL unit get lost, then that will cause only that slice to be non-renderable. On the other hand, if the IDR picture is a complete NAL unit, then the loss of *any* packet will cause the whole picture to be non-renderable.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120812/ef9738b6/attachment-0001.html>
More information about the live-devel
mailing list