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

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

--- Comment #3 from Aaron Colwell <acolwell@chromium.org> 2012-06-15 22:14:03 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > 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.

If we are going to use heuristics, I want to make sure we define them well so
that everyone implements them the same way. Using the largest inter-frame gap
could work. We would have to figure out what to do if the first media segment
appended only has a single frame and we don't know the duration. Don't laugh!
I've seen files where the first cluster only contains the keyframe. Perhaps we
could define a reasonable initial value for the largest inter-frame gap, say
250ms, and use that until we actually see a multi-frame media segment and then
update to the measured value. 

We may need to specify different starting values for audio and video since
250ms seems rather high for a default audio frame length. Something closer to
30-60ms would probably be better.

> > 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.

Yes. I think your suggestion above is probably the best way to handle all these
cases.

-- 
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 Friday, 15 June 2012 22:14:06 UTC