Webkit doesn't seek when readyState is HAVE_METADATA #28

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

Comments

Projects
None yet
4 participants
@tsenart
Contributor

tsenart commented Nov 14, 2011

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

This comment has been minimized.

Show comment
Hide comment
@eric-carlson

eric-carlson Nov 15, 2011

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.

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.

@yvg

This comment has been minimized.

Show comment
Hide comment
@yvg

yvg Nov 15, 2011

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.

yvg commented Nov 15, 2011

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

This comment has been minimized.

Show comment
Hide comment
@eric-carlson

eric-carlson Nov 15, 2011

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

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

@tsenart

This comment has been minimized.

Show comment
Hide comment
@tsenart

tsenart Nov 15, 2011

Contributor

@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.

Contributor

tsenart commented Nov 15, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@eric-carlson

eric-carlson Nov 15, 2011

@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?

@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?

@tsenart

This comment has been minimized.

Show comment
Hide comment
@tsenart

tsenart Nov 15, 2011

Contributor

@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.

Contributor

tsenart commented Nov 15, 2011

@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.

@kinetiknz

This comment has been minimized.

Show comment
Hide comment
@kinetiknz

kinetiknz Nov 17, 2011

Contributor

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).

Contributor

kinetiknz commented Nov 17, 2011

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).

@tsenart

This comment has been minimized.

Show comment
Hide comment
Contributor

tsenart commented Nov 21, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment