<div dir="ltr"><div><div><div><div><div>I have been using a network emulator to introduce network issues to test the robustness of our code and found this conversation timely.<br><br></div>In some of my tests which are rtp over tcp, the lost packets can be re-transmitted. The ReorderPacketBuffer then can take the rtp packets inside that may be out of sequence and insert them in the linked list of rtp packets that make up the NAL before getting the magical marker bit and calling your afterGettingFrame. <br><br></div>rtp over udp can be out of order just by the path they may take, but there can be no retransmit,. <br><br></div>I have pushed beyond reasonable limits and have seen the classical failure tell-tails in popular decoders. (I mean 4K camera at max quality with 3M keyframes)<br><br></div>dropped keyframes = ghosting artifacts..<br></div>truncated keyframes = great video from top down to a point then ghosting, corruption or line copy to end of frame, Some are quite entertaining and would give Van Gough a run for his money.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 23, 2016 at 2:44 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I have never quite got the advantage of frame fragmentation, i.e. let's consider a large intra frame and the two cases:<br>
><br>
> 1) Sending the intra frame as a single huge packet<br>
><br>
> 2) Sending the intra frame as a series of smaller packets<br>
<br>
Your use of the word ‘packet’ here is strange (and, I presume, wrong), because the word ‘packet’ usually means an atomic unit of data sent over a network.  I presume, instead, that you meant to ask about the difference between:<br>
        1) Sending an intra frame (i.e., ‘key frame’) as a single H.264 NAL unit, versus<br>
        2) Sending an intra frame (i.e., ‘key frame’) as a sequence of H.264 ‘slice’ NAL units<br>
In each case, each NAL unit (unless it’s very small) will be fragmented into several network (i.e., RTP/UDP/IP) packets - which can be up to 64 kBytes in size, but are typically about 1500 bytes.  The loss of *even one* of these packets will make the whole NAL unit useless (i.e., unrenderable) for the receiver.<br>
<br>
> The behaviour for the two cases in the case of packet loss:<br>
><br>
> 1) The whole intra frame is lost, must wait for the next one<br>
<br>
Correct<br>
<br>
> 2) A one slice of the intra frame is lost .. making the whole intra-frame useless.<br>
<br>
Incorrect.  The video decoder/renderer will be able to decode/render/display the other slices of the frame - apart from the one that was lost.  This might look strange, but at least you’ll be able to see something.<br>
<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" rel="noreferrer" target="_blank">http://www.live555.com/</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/<wbr>mailman/listinfo/live-devel</a><br>
</blockquote></div><br></div>