[whatwg] Proposal: Media element - add attributes for discovery of playback rate support

[Ian Hickson]

On Wed, 17 Jul 2013, Edward O'Connor wrote:
> > On Wed, 30 Jan 2013, Peter Carlson (carlsop) wrote:
> >>
> >> Problem: The problem is that the supported playback speeds of a media 
> >> element may vary per media item (e.g., an on-demand movie) and as 
> […]
> >> Recommendation: We suggest that the application should be able to 
> >> discover the available speeds at which it can play the media element. 
> […]
> > This seems less good than just having the browsers support all playback 
> > speeds, e.g. by decoding into a local buffer. Why would we prefer to 
> > expose the media's limitations rather than removing them?
> 
> Live streams. Do you really think browsers should have to pause and 
> buffer a live stream to make it possible to play it in FFWD?

Sure. Just like a DVR.


On Wed, 17 Jul 2013, Peter Carlson (carlsop) wrote:
> 
> For on-demand movies or VOD, the available playback speeds may be 
> determined by the server of the content. This cannot be overcome by 
> client-side buffering.

Um... no? The user should be in control. Always.


On Thu, 18 Jul 2013, John Mellor wrote:
>
> If the user is speeding up playback to improve their productivity (spend 
> less time watching e.g. a lecture), then they may well be willing to 
> wait until enough of the video is buffered, since they can do something 
> else in the meantime.
> 
> For example by spending 30m buffering the first half of a 1 hour live 
> stream, the user could then watch the whole hour at double speed.
> 
> Obviously the UI should make it clear what's going on (rather than 
> lengthily buffering without explanation).

Right. Just like a DVR.


On Thu, 18 Jul 2013, Brendan Long wrote:
>
> This is how DVR's work with live TV and people seem to like it (well, 
> they like it more than not being able to fast-forward at all..).

Indeed.


On Thu, 18 Jul 2013, Eric Carlson wrote:
> 
> And it works because a DVR has lots of disk space. This is not the case 
> with all devices that support the media element.

Obviously device limitations are difficult, but realistically, 
HTML-capable devices now regularly have gigabytes of storage available.

The spec doesn't require that the entire infinite stream be buffered, only 
as much as is possible; there's a whole bunch of prose about how to handle 
discarding content once the buffer is full ("earliest possible position" 
and so on).


> Even a DVR, however, won't always let you change the playback speed. For 
> example it isn't possible to play at greater than 1x past the current 
> time when watching a live stream.

Well obviously you can't fast-forward into the future, but you can pause 
and buffer some, or rewind if you've been watching for a while, and 
fast-forward through the buffer.


> If I am watching a live stream and I try to play past the end of the 
> buffered video, my DVR drops back to 1x and won't let me change the 
> speed. It doesn't automatically pause and buffer for a while so it can 
> play at a faster rate.

Sure. That's fine. The spec has lots of prose that describes the 
requirements around how to handle playing content back when there's not 
yet content available to play back.


> It isn't always possible to play a media stream at an arbitrary speed. 
> It is foolish to pretend otherwise as the current spec does.

If you can play it at 1x speed, then you can rewind and play it at 2x 
speed, or 0.5x speed. That's all the spec says.


On Thu, 18 Jul 2013, Brendan Long wrote:
>
> That makes sense, but we also don't want to limit ourselves to playback 
> speeds that a server supports when the client /does/ have data buffered.

Right.


> What if we added a "supportedPlaybackRates" attribute, which holds an 
> array of playback rates supported by the server, plus (optionally) any 
> rates the user agent can support due to the currently buffered data 
> (possibly requiring that the user agent have enough data buffered to 
> play at that speed for some amount of time).

Wouldn't that be 0.0 .. Infinity, basically?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'