[Bug 17072] Define behavior for a break in contiguous appending

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

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #2 from Mark Watson <watsonm@netflix.com> 2012-06-05 20:20:32 UTC ---
(In reply to comment #0)
> 
> This problem raises several questions:
> 1. Can this happen in ISO BMFF or other formats we might want to support?

ISO BMFF no, as we have the specification now. The last sample in a standard
ISO file can have indeterminate duration, but for movie fragments there is
always a sample duration (the default in the Movie Extends applies if nothing
else does).

> 2. How should we signal that a discontinuity is happening?

Another way to think of it is that each append places the video frames at their
specified positions on the timeline. What is left to work out is whether the
gap between the last frame of one segment and the first frame of the next is so
large that there must be content missing and playback should stall when you get
to that point.

Would it be ok to suggest that implementations apply heuristics when there is
some doubt ? For example if the gap is bigger than twice the largest
inter-frame gap observed.

> 3. Should the WebM section be updated to mandate duration information on the
> last frames? This requirement would likely exclude discontiguous appends on a
> majority of current WebM content.
> 4. Should we restrict the situations where non-contiguous appends can occur?

What kind of restriction ? I can see four applications for a discontiguous
append:
(a) the user seeks to some point in the future. The append probably occurs with
the video element in a "stalled" state with playback position equal to the
start of the new segment.
(b) video data for some segment happens to arrive at the client earlier than
for the "next" segment - perhaps because the JS is getting fancy with parallel
downloads etc. The segment filling the gap will arrive soon (and if it doesn't
playback should stall)
(c) In the live case, playback has fallen too far behind the "live leading
edge" (due to playback stalls) and the player decides to skip a segment or two
to catch up. It will need to set the playback position to the start of the
skip-to segment. This is pretty much like a seek from the Media Element
perspective
(d) Imperfect segmentation on a bitrate switch means there is a missing frame
or two between the end of one segment and the beginning of the next. Heuristics
as suggested above essentially means being lenient with imperfect segmentation
and playing back with a couple of frame drops vs stalling altogether.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 5 June 2012 20:20:35 UTC