[whatwg] media element playback rates

[Kevin Calhoun]

On Nov 2, 2007, at 10:34 AM, Ian Hickson wrote:

> On Fri, 2 Nov 2007, Dave Singer wrote:
>>
>> About playbackRate and defaultPlaybackRate in the current  
>> specification of
>> media elements, the logic that's currently necessary to set a media  
>> element to
>> play at rate n is somewhat convoluted:
>>
>> 	If the media is paused
>> 		1) Set the defaultPlaybackRate to n.
>> 		2) Issue play().
>> 	If the media is not paused
>> 		- Set the playbackRate to n.
>>
>> And there's a distinct lack of permanence to setting playbackRate on
>> playing media to alter its rate. Once media is paused, the play()  
>> method
>> will reset the rate of the media (and playbackRate itself) to
>> defaultPlaybackRate instead of to the previous value of playbackRate,
>> which we think is unexpected.
>
> The current design is built around three use cases:
>
> 1. Being able to implement fast-forward, rewind, or slow-motion  
> easily.
> 2. Being able to change the playback rate for watching videos quickly.
> 3. Being able to do both in the same player.
>
> In the current model:
>
> Fast-forward and rewind just consists of calling play() to ensure the
> playback head is moving and then changing 'playbackRate', resetting to
> normal is just a call to play(); changing the default playback rate
> without affecting that consists of changing 'defaultPlaybackRate'  
> and, if
> the UA isn't in a fast-forward, rewind, or slow-motion mode, and isn't
> paused, also calling 'play()'.

A consideration in raising this issue now is that in our prototyping  
we rediscovered the need for the media engine to be informed in  
advance, whenever possible, of the rate at which it will be required  
to play, in order to prepare itself appropriately. In the current  
model, the play() method will be invoked, typically, just after  
reaching a state in which it's prepared to play through at the  
defaultPlaybackRate, but immediately after that it may --   
inadequately prepared, alas -- be required to keep up at fast forward  
speeds, with predictably halting results.

In the alternative model Dave described, the same operations you  
enumerated are also readily performed as below, and the media engine  
is better informed of what will be required of it. Of course arbitrary  
changes in rate during playback may be impossible to accommodate  
without running out of data and having to pause, but preparation in  
advance of playback should be more likely to be smooth than the  
current model allows us to make it.

Fast-forward: set the playbackRate to 2.0 (or whatever is deemed  
sufficiently "fast"), play()
Resetting to normal, set the playbackRate to 1.0, which is defined as  
"normal", issue play() if not already playing
Changing the default playback rate: N/A. But you can achieve whatever  
playback rate you want that the media allows by setting playbackRate.

- Kevin Calhoun
   Apple/QuickTime