1498312 - Fix FrameList::PopFrame in jitter_buffer.cc

Status: NEW

(Core :: WebRTC: Audio/Video, enhancement, P3)

Description

[Dan Minor [:dminor]]

A comment was left on this function as follows:

// Find a Frame which (may) include seq_num
// Note: if we don't have an end for the frame yet AND there are multiple Frames
// with the same timestamp being input, in theory you can get packets
// for a later Frame mixed with an earlier one where there's a reordering.
// e.g. for <frame 1: 1 2 3> <frame 2: 4 5 6> and we receive
//          1 2 4 3 5 6
// or       4 1 2 3 5 6
// we'll return <frame 1> for packet 4, and at some point it needs to move to
// <frame 2>.  You can't key off isFirstPacket or kNaluStart because the OOO packet
// may be 5:
//          1 5 2 3 4 6
//          1 5 3 4 2 6 etc

// This can be done by re-characterizing 4 when <frame 1> becomes complete
// and we find it doesn't include 4.  Perhaps a better abstraction would be
// to keep the packets in a single sorted list (per timestamp or not,
// doesn't really matter), and then on insertion look to see if it's in a
// complete unit (kNaluComplete or kNaluStart ... kNaluEnd sequence), and
// remove the set *then*.
//
// If we instead limit multiple frames with the same timestamp to
// kNaluComplete (single-packet) frames (i.e. Mode 0 H264), it's simpler.
// You do need to be careful to pull off Frames only if they're contiguous
// in sequence number to the previous frame, but that's normal since you
// can get 4 5 6 1 2 3
//
// Note that you have to be careful reordering still:
// <frame 1: 1> <frame 2: 2 3 4>
// and arrival 2 1 3 4
// means you must not match the frame created for 2 when 1 comes in

// XXX This is NOT implemented here; we need to redo this