This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html Section: http://www.whatwg.org/specs/web-apps/current-work/#the-ready-states Comment: Fix HAVE_METADATA and HAVE_CURRENT_DATA when seeking and at playback end Posted from: 83.218.67.122 User agent: Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.8.131 Version/11.10
http://lists.w3.org/Archives/Public/public-html/2011Feb/0441.html http://lists.w3.org/Archives/Public/public-html/2011Feb/0451.html Based on this discussion, some spec changes are in order. On Fri, 25 Feb 2011 22:45:16 +0100, Philip Jägenstedt <philipj@opera.com> wrote: > Suggestion: > > * buffered ranges are inclusive > * whenever currentTime is not in one of the ranges, readyState <= > HAVE_METADATA > * when currentTime is in one of the ranges, readyState >= > HAVE_CURRENT_DATA > * no special casing of EOS > > This would mean that readyState would never go back to HAVE_METADATA > during normal playback, only when first loading the resource and when > seeking to an unbuffered position. At least to me, this seems consistent > and logical. On Sat, 26 Feb 2011 14:46:50 +0100, Philip Jägenstedt <philipj@opera.com> wrote: > I'd much prefer if we kept the theoretical model and definitions simple > by not assuming that there's such a thing as an imaginary epsilon > differentiating two times that are indistinguishable both to the browser > internals and via the DOM API. The definition of "potentially playing" might need readjusting as well, as it was changed during that discussion.
Wasn't this all fixed already?
(In reply to comment #2) > Wasn't this all fixed already? Yes: http://html5.org/r/6177 http://html5.org/r/6178 http://html5.org/r/6179 http://html5.org/r/6180
mass-move component to LC1