26847 2014-09-18 15:02:55 +0000 Allow restarting playback for media resources which are not random access but can be streamed anew 2014-10-08 14:27:46 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED P3 normal Unsorted 1 philipj ian acolwell dalecurtis ian mike silviapfeiffer1 contributor oldest_to_newest 111744 0 philipj 2014-09-18 15:02:55 +0000 Media resources served without byte ranges support can normally be restarted, but there's no way to effectively seek to any point. Currently Chromium reports no seekable ranges in this case, but that makes it impossible to seek to 0, which is how the loop attribute is specified. There's a Chromium bug and code review discussing this: https://crbug.com/412562 https://codereview.chromium.org/562493003/ Here are the 3 candidate solutions we have, from comment #22: > 1. Report seekable ranges [0, epsilon] > > Allowed by spec, although the epsilon obviously doesn't correspond to anything > in the media resource. What happens when currentTime is set to epsilon or > >epsilon while paused? Per current spec, one should end up at epsilon, but that > seems like it would need special casing to support. If the earliest possible > position is not 0, should it instead be [n,n+epsilon]? > > 2. Report no seekable ranges but allow seeking to zero by restarting the request > > Needs a spec change to allow the seek to 0. > > 3. Report seekable range [0,0]. > > Needs a spec change to allow an empty range. What do you all think about this > one? Option 3 seems to be the least strange at the moment. Obviously, if the earliest possible position n is not 0, it would be [n,n]. The spec requires the range end to be greater than the range start, so that would be the core of the change. 111751 1 ian 2014-09-18 16:55:01 +0000 Why not just buffer the whole file and thus make it entirely seekable? If it's a live stream, you can't seek to 0. If it's a non-live stream, you can seek to anywhere, it's just not buffered. You just have to download the file again. So the seekable range should be [0,end]. 111773 2 philipj 2014-09-18 21:30:53 +0000 (In reply to Ian 'Hixie' Hickson from comment #1) > Why not just buffer the whole file and thus make it entirely seekable? > > If it's a live stream, you can't seek to 0. > > If it's a non-live stream, you can seek to anywhere, it's just not buffered. > You just have to download the file again. So the seekable range should be > [0,end]. It's resource served without "Accept-Ranges: bytes" but with a Content-Length, i.e. non-live and non-seekable. If that resource doesn't fit in cache or it's not cached due to some policy, then seeking amounts to loading it all over again. That seems worse than not allowing seeking at all, TBH. It's technically really easy to make looping work though, so if one wants to implement that before "buffer everything" or whatever, how should it be exposed on HTMLMediaElement? 111810 3 ian 2014-09-19 17:22:07 +0000 Being able to seek is better than not being able to seek, even if it's slow. In practice, you don't have to cache the whole thing. Just cache what you can. That way if the user is suddenly "wtf was that", they can seek back a few seconds easily, but if they want to go back an hour, the file has to be reloaded from the start. If the user finds he can't seek, but knows he can just reload the page and fast-forward to what he wants to see, then the browser being stubborn and not letting him seek is just frustrating and annoying, IMHO. 111835 4 dalecurtis 2014-09-19 19:40:40 +0000 Seeking practices aside. The main question is whether TimeRanges are allowed to represent a single moment in time or if they must always represent a range. acolwell@ offered the following hypothetical: Consider a playing video which has been paused, due to memory constraints the cache is evicted such that only a single frame at time T is available. Is it reasonably to expose seekable as [T,T] in this case? 111844 5 acolwell 2014-09-19 20:25:41 +0000 Actually I was more thinking in terms of whether .buffered could be [n,n] in the case mentioned in the last sentence. The .seekable attribute could also be that as well, but I was mainly interested in having the "should we allow an instant to be represented w/ TimeRanges" question answered since the current spec text doesn't allow it. That feels like the core question here. What the UA exposes via .buffered and .seekable seems more like a quality of implementation issue. 111919 6 ian 2014-09-22 16:28:23 +0000 Yeah, the spec should probably allow "empty" ranges (not really "empty" since the start and end are both inclusive). 112152 7 contributor 2014-09-24 22:48:20 +0000 Checked in as WHATWG revision r8819. Check-in comment: Allow TimeRanges to contain 'empty' ranges (not really empty, they contain one moment in time). Add some text admonishing implementations that don't allow one to seek arbitrarily when it's actually possible just inconvenient or slow. https://html5.org/tools/web-apps-tracker?from=8818&to=8819 112826 8 philipj 2014-10-08 14:27:46 +0000 Thanks, the spec change looks good. On the Chromium side, we ended up reporting [0,0] for seekable ranges for in some cases, i.e. what the spec calls "a poor implementation." It would be nice to improve this, but from what I understand it's quite a bit of work.