- From: <bugzilla@jessica.w3.org>
- Date: Fri, 05 Oct 2012 18:01:30 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18615 --- 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