<html><head><base href="x-msg://586/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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:<div><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>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.)</div><div><br></div><div>(Did you not notice these messages in your console output??)</div><div><br></div><div>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</div></div><div><span class="Apple-tab-span" style="white-space:pre"> OutPacketBuffer::maxSize = </span>1<span class="Apple-tab-span" style="white-space:pre">00000; // allow for some possibly large H.264 frames</span></div><div>to</div><div><span class="Apple-tab-span" style="white-space:pre"> OutPacketBuffer::maxSize = 200000; // allow for some possibly large H.264 frames</span></div><div>and recompiling the LIVE555 Media Server.</div><div><br></div><div>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.</div><div><br></div><div>[*]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.</div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>