This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26847 - Allow restarting playback for media resources which are not random access but can be streamed anew
Summary: Allow restarting playback for media resources which are not random access but...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-18 15:02 UTC by Philip Jägenstedt
Modified: 2014-10-08 14:27 UTC (History)
5 users (show)

See Also:

Attachments

Description Philip Jägenstedt 2014-09-18 15:02:55 UTC 
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.
Comment 1 Ian 'Hixie' Hickson 2014-09-18 16:55:01 UTC 
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].
Comment 2 Philip Jägenstedt 2014-09-18 21:30:53 UTC 
(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?
Comment 3 Ian 'Hixie' Hickson 2014-09-19 17:22:07 UTC 
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.
Comment 4 Dale Curtis 2014-09-19 19:40:40 UTC 
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?
Comment 5 Aaron Colwell 2014-09-19 20:25:41 UTC 
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.
Comment 6 Ian 'Hixie' Hickson 2014-09-22 16:28:23 UTC 
Yeah, the spec should probably allow "empty" ranges (not really "empty" since the start and end are both inclusive).
Comment 7 contributor 2014-09-24 22:48:20 UTC 
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
Comment 8 Philip Jägenstedt 2014-10-08 14:27:46 UTC 
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.