W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2012

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 05 Oct 2012 18:01:30 +0000
Message-Id: <E1TKCDK-0003Z6-Jr@jessica.w3.org>
To: public-html-bugzilla@w3.org

--- Comment #2 from Aaron Colwell <acolwell@chromium.org> 2012-10-05 18:01:30 UTC ---
(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.

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?

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, 5 October 2012 18:01:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:34 UTC