Skip to content
This repository

Webkit doesn't seek when readyState is HAVE_METADATA #28

Open
tsenart opened this Issue November 14, 2011 · 8 comments

4 participants

Tomás Senart Eric Carlson Yves Van Goethem Matthew Gregan
Tomás Senart

Here: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#seeking

Note that it's an error to seek while in readyState HAVE_NOTHING. All other states are valid, including HAVE_METADATA.

Here: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-ready-states

Under HAVE_METADATA: "The API will no longer raise an exception when seeking."

Also note in that section that canplay is fired when the readyState is HAVE_FUTURE_DATA.

Eric Carlson

All true, but the spec also says: http://dev.w3.org/html5/spec/the-iframe-element.html#seeking

If the (possibly now changed) new playback position is not 
in one of the ranges given in the seekable attribute, then 
let it be the position in one of the ranges given in the 
seekable attribute that is the nearest to the new playback 
position.

In the test you set currentTime when seekable() returns an object with no ranges, so the seek time is changed to 0. The spec doesn't mandate that a file be seekable when it reaches HAVE_METADATA.

Yves Van Goethem
Owner

Tomas: You labeled this issue "reported to vendor" can you include the links to bug reports into your description if they are existing and if not (like Opera) just precise which browsers, thanks.

Eric Carlson

As written, this issue is about WebKit. In this case the vendor reported the issue to itself: https://bugs.webkit.org/show_bug.cgi?id=72145

Tomás Senart

@eric-carlson Then I think this part of the spec left room to interpretation (once again). If all readyState states are valid for seeking, but none is mandatory, then is it up to the implementor to decide which one(s)?
In Firefox they make it possible to seek on all valid states and I think that makes sense and doesn't break expectations.

Eric Carlson

@tsenart - readyState is mostly orthogonal to seek-ability - seekable() is there to allow a script to find out what range(s) are seek-able.

Then I think this part of the spec left room to interpretation (once again)

Yes, and I think this is entirely appropriate. If the spec required specific seekable values for readystate, what would we do with servers that do not support byte-range requests?

Tomás Senart

@eric-carlson I understand the use of seekable but perhaps when the metadata is fetched it makes sense to retrieve this information as well. AFAIK on the same HTTP request you do for fetching metadata you can also pass an empty range header Range:. Which will retrieve Accept-Ranges: bytes and Content-Range: bytes 0-1/xxxxxx.
This allows you to be seekable right from the HAVE_METADATA state right? If the server doesn't support range requests the seekable attribute should either be empty or the full duration. If the full duration is chosen the seek should happen immediately on currentTime = xxx, the browser should buffer until that point and continue playback.

Matthew Gregan

As @tsenart says, the UA can (in most cases) detect that the media is seekable by inspecting the HTTP response headers. In situations where this is not possible, there does seem to be a gap in the spec--as far as I can tell, the author is forced to poll seekable until the target position is available since there's no event tied directly to updates of the seekable attribute (the progress event is probably the closest thing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.