- From: <bugzilla@jessica.w3.org>
- Date: Fri, 22 Mar 2013 15:30:14 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21334 Aaron Colwell <acolwell@chromium.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |acolwell@chromium.org Assignee|adrianba@microsoft.com |acolwell@chromium.org --- Comment #1 from Aaron Colwell <acolwell@chromium.org> --- (In reply to comment #0) > The section on “Seeking” 2.4.3 in the 12 March 2013 Editors Draft contains > the following text (“Seeking“ is 3.4.3 in the first public working draft and > the text is the same). > > The media element feeds data from the media segments into the decoders until > the new playback position is reached. > > “feeds data from the media segments” can be interpreted in many different > ways. > > What does this actually mean in terms of what the user sees? At least in the > following scenarios; > - The new playback position is a RAP but not the start of a DASH segment > - The new playback position is not a RAP > > How much is implementation dependent? This is a pretty old part of the spec. I'll update it to something along the lines of "The media element feeds coded frames from the active track buffers starting with the closest random access points that are before the new playback position." I'll also add a definition for "active track buffers" that indicates that these are the track buffers that are associated with the selected tracks. This is a subset of the tracks in the SourceBuffer objects that are in MediaSource.activeSourceBuffers. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 22 March 2013 15:30:19 UTC