[Bug 18615] Define how SourceBuffer.buffered maps to HTMLMediaElement.buffered

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

--- Comment #3 from Philip Jägenstedt <philipj@opera.com> 2012-10-08 09:03:01 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > That sounds sensible, but I think there's a bug in the definition for "ended".
> > If the video SourceBuffer has [0,10] and [20,30] buffered and the audio
> > SourceBuffer has [0,15] buffered, does it really make sense to report [0,30]
> > even though no data at all is available for [15,20]?
> 
> You're right. I can think of two routes to avoid this situation.
> 
> Solution 1:
> In MediaSource.endOfStream(), check to make sure that the last ranges in the
> activeSourceBuffers overlap and throw an exception if they don't. This would
> prevent a transition to "ended" when this situation occurs.

Would you do this only for endOfStream(), or also for endOfStream("network")?
In the network error case, it doesn't really make sense.

> Solution 2:
> 1. Collect all the ranges that intersect and then find the highest end
> timestamp of that set. 
> 2. remove(highest end timestamp, duration) 
> 3. Update duration to highest end timestamp.
> 
> Currently Chrome implements solution 1 with the added criteria that the current
> playback position must be in the last range. If it isn't then endOfStream()
> throws an exception. This was to prevent playback from getting stalled if there
> was a gap in the buffered data between the current position and the last
> ranges. This second condition may not be necessary anymore since you can
> append() your way out of "ended" now.
> 
> What do you think? Do you have a preference here or an alternate suggestion?

I do think it would be nice to have the same logic for all cases of endOfStream
to reduce the overall complexity. In other words, something like solution 2,
where data that cannot be used is thrown away, sounds slightly preferable.
However, I don't feel strongly about this, it's also a question about what
behavior would be the most useful to authors.

-- 
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 Monday, 8 October 2012 09:03:12 UTC