[Live-devel] A Problem of RTSP Server

[Eden Lee (Gorilla)]

Yes Sir.,

I change OutPacketBuffer::maxSize to be 300000. The display of local RTSP client is correct. Unfortunately, the remote client's display is still incorrect. Do you have any idea about this situation?

Expect your response. Thank you.

Best regards,

Eden

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, August 13, 2012 12:51 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] A Problem of RTSP Server

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/20120815/c1b42969/attachment.html>