[Bug 27242] Clarify how track buffer ranges are updated.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27242

Matt Wolenetz <wolenetz@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wolenetz@google.com

--- Comment #3 from Matt Wolenetz <wolenetz@google.com> ---
I'm noting some further things I believe need clarification in track buffer
range calculation in the spec:

By example:

1) Append a video keyframe buffer A, whose presentation interval is roughly:
   [A..............)
2) Append another video keyframe buffer B, whose presentation interval is
contained completely within A's: (B's PTS) >= ((A's PTS) + (1 microsecond)) and
(B's PTS+duration) < (A's PTS+duration):
      [B......)

What should be the track's buffered ranges at this point? Should A's duration
be truncated to join the end of A with the beginning of B? Ambiguity exists:
the spec isn't clear whether the track buffer contains:
   [A.[B......)....) ---> Render A, then B, then A again? Unlikely this is
desired.
Or:
   [A)[B......) ---> Render A, then B, then done (and possible gap is
introduced until next buffered range).

A further complexity is introduced if the initial append were followed by some
dependent (non-key) frames:
   [A..............)[a1.....][a2.....][a3.....]
After appending B, the impact of the spec ambiguity increases. Should the track
buffer then contain:
   [A.[B......)....)[a1.....][a2.....][a3.....] ---> Render keyframe A, then
keyframe B, then back to keyframe A again, then dependent frames a1, a2, and
a3? Unlikely this is desired, especially if both A and B ended at the same
time.
Or:
   [A)[B......) ---> Render A, then B, then done (and even more likely there is
a gap introduced until next buffered range).

What should the buffered result be if an app issues Remove() to remove exactly
the presentation interval for B? I think the sanest approach might be just:
   [A) --> just the first tiny bit of A, then a potentially even larger gap.

Finally, the spec is not clear regarding how much of a "gap" can be introduced
(in audio or video tracks) before a previously contiguous buffered range is
split in two. In general, how close to a range must a coded frame group's
presentation interval be to be considered continuous, contained within, that
range? The coded frame processing algorithm describes this clearly for parsing
a stream of new frames, but the spec is unclear regarding exactly how other
operations like scattered appends, overlapped appends, removes, etc result in
buffered range(s).
At least one implementation (Chromium) tracks a maximum inter-frame distance
for each track and uses this in a heuristic to determine range
membership/continuity.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 21 March 2015 00:03:56 UTC