- From: <bugzilla@jessica.w3.org>
- Date: Fri, 14 Sep 2012 18:00:45 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18587 --- Comment #3 from Aaron Colwell <acolwell@chromium.org> 2012-09-14 18:00:45 UTC --- (In reply to comment #2) > Phrased like that, it sounds like an implementation would rewrite the > overlapping segment to drop excess data before giving it to the decoding > pipeline. Implementing TextTrackCue.pauseOnExit already requires pausing at the > granularity of a single audio sample or video frame, so I think that if anyone > were to implement this at all, that's a more likely implementation technique. > > If there are implementors interested in handling this situation well, I think > it should be spec'd in terms of pausing at duration and clamping buffered > duration, leaving the technique open. Some stuff in the spec has changed since I last commented on this bug but I believe this issue is still present. I think this bug is now referring to step 3 of the duration change algorithm (http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#duration-change-algorithm). Initially I thought it made sense to add a step after step 3 to talk about this, but it doesn't seem appropriate since this information isn't about the duration change algorithm itself. Would adding a note below step 3 along these lines be ok? Note: This preserves audio frames that start before and end after the duration. The user agent must end playback at duration even if the audio frame extends beyond this time. -- 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, 14 September 2012 18:00:53 UTC