This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dev.w3.org/html5/spec/media-elements.html#dom-media-seekable http://dev.w3.org/html5/spec/media-elements.html#dom-media-seek The HTMLMediaElement seek algorithm clamps the requested position to the closest seekable range, so anything outside the reported seekable ranges is impossible to seek to. It's not defined in MSE how to report the seekable attribute and it's not clear that there's a good answer, since the browser isn't in a good position guess what ranges the application will be able to provide. Possible solutions: 1. Expose [0, duration]. This is still broken because it's a complete lie for Infinite duration, and for implicit duration it makes it impossible to seek beyond the already appended data. 2. Expose no seekable ranges at all, and say that the clamping step of the seeking algorithm should be skipped for MSE. That works, but isn't exactly elegant.
(In reply to comment #0) > http://dev.w3.org/html5/spec/media-elements.html#dom-media-seekable > http://dev.w3.org/html5/spec/media-elements.html#dom-media-seek > > The HTMLMediaElement seek algorithm clamps the requested position to the > closest seekable range, so anything outside the reported seekable ranges is > impossible to seek to. > > It's not defined in MSE how to report the seekable attribute and it's not clear > that there's a good answer, since the browser isn't in a good position guess > what ranges the application will be able to provide. > > Possible solutions: > > 1. Expose [0, duration]. This is still broken because it's a complete lie for > Infinite duration, and for implicit duration it makes it impossible to seek > beyond the already appended data. > > 2. Expose no seekable ranges at all, and say that the clamping step of the > seeking algorithm should be skipped for MSE. That works, but isn't exactly > elegant. I prefer option 1. I think in most cases it will be the right thing to do because the expectation is that the web application will append media for all portions of the timeline. For implicit duration I think it is ok to prevent seeking beyond the appended data since the application hasn't given any indication that this should be allowed. If the application knows the true duration it can always explicitly set MediaSource.duration and then the seekable range would expand to that and seeking outside the appended region would be allowed. In the case of Infinity perhaps we should use the last end time in SourceBuffer.buffered across all SourceBuffers since that appears to be the best way for the UA to guess about what sections of the media will be available. It isn't perfect, but it seems like the closest thing to what would happen in a live stream. Seem reasonable?
Yeah, this sounds OK. My main worry was that authors would fail to notice the restriction in the implicit case and not notice until on a slow network, but reconsidering I don't think that's a very realistic scenario.
Changes committed: http://dvcs.w3.org/hg/html-media/rev/c3de559a1c37
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#htmlmediaelement-attributes looks OK.