[MSE] Bug 18615 - HTMLMediaElement.buffered behavior in "ended" state

Hi,

I'd like to restart the discussion around Bug
18615<https://www.w3.org/Bugs/Public/show_bug.cgi?id=18615> so
we can get closer to closing it out. The gist of the problem is how should
the buffered property and playback behavior change when the
MediaSourceenters the ended state.

For well behaved applications that append multiplexed data the behavior is
relatively straight forward and I think the existing spec text works fine.
The problems appear when audio & video are appended with different
SourceBuffers and buffered regions of each SourceBuffer may be disjoint in
several regions when endOfStream() is called.

Here are some questions to start the discussion:

1. What should the behavior be if there are gaps between the current
playback position and the end of the buffered data when endOfStream() is
called? For example, the current position is 10 and SourceBuffer.buffered
reports [0, 15) and [20, 30).

1a. Should playback continue through this gap?
1b. Should the duration be truncated to the range that contains the current
position?
1c. Should an exception be thrown by endOfStream() if the current playback
position isn't in the last range?
1d. Should a "network error" be signalled when the current position reaches
the end of the range? This is roughly equivalent to an
HTMLMediaElementbeing unable to fetch data it needs.

2. If multiple SourceBuffers are being used and they don't contain roughly
the same buffered ranges when endOfStream() is called, then how should
playback proceed? Philip give an example in the bug where we have a video
SourceBuffer with the following ranges [0, 10], [20,30]  and an audio
SourceBuffer with the range [0,15]

2a. Should playback continue to the highest buffered data and play through
the gaps?
2b. Should the buffered data be truncated to the intersection of the ranges?

This is just the questions I can think of off the top of my head. These
situations don't really happen in traditional HTMLMediaElement playback so
I think we are blazing new trails here.

Aaron

Received on Thursday, 10 January 2013 18:02:42 UTC