[Live-devel] Fragmented intra frames

[Jeff Shanab]

I have been using a network emulator to introduce network issues to test
the robustness of our code and found this conversation timely.

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.

rtp over udp can be out of order just by the path they may take, but there
can be no retransmit,.

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)

dropped keyframes = ghosting artifacts..
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.



On Fri, Sep 23, 2016 at 2:44 PM, Ross Finlayson <finlayson at live555.com>
wrote:

> > I have never quite got the advantage of frame fragmentation, i.e. let's
> consider a large intra frame and the two cases:
> >
> > 1) Sending the intra frame as a single huge packet
> >
> > 2) Sending the intra frame as a series of smaller packets
>
> 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:
>         1) Sending an intra frame (i.e., ‘key frame’) as a single H.264
> NAL unit, versus
>         2) Sending an intra frame (i.e., ‘key frame’) as a sequence of
> H.264 ‘slice’ NAL units
> 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.
>
> > The behaviour for the two cases in the case of packet loss:
> >
> > 1) The whole intra frame is lost, must wait for the next one
>
> Correct
>
> > 2) A one slice of the intra frame is lost .. making the whole
> intra-frame useless.
>
> 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.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160923/c2804447/attachment.html>