HTMLMediaElement defaultPlaybackRate and playbackRate

   Do we really need both "defaultPlaybackRate" and "playbackRate"? We  
(Apple) argued last year that two rate attributes aren't as useful as  
they might seem, and while Ian didn't agree with our arguments at the  
time I wanted air them one more time before this part of the spec  
finally solidifies.

   At the time we suggested that the element only needs one rate  
attribute, and Ian explained the use cases behind the current design:

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

> 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()'.
>

   This model is logical at first glance, but it actually prevents a  
media engine from making important optimizations. A media engine has  
to do quite a bit of work to prepare for playback: scheduling IO to  
load media into memory, preprocessing and decompressing data  
sufficiently ahead of the current time to ensure smooth playback,  
etc.  A *very* important factor in this setup is the rate at which  
playback will occur, because playback rate dictates how many samples,  
and which samples, to load.

   If I want to play at 2x, the current spec requires me to call  
play() and then set the playbackRate to 2.0. This is likely to cause  
noticeable artifacts, as play() will cause media to be queued to play  
at defaultPlaybackRate and it is very likely that some will hit the  
output device(s) before the rate change takes effect. Worse yet, some  
media engines may not be able to perform rate changes on the fly and  
will have to tear down and rebuild their output chains to deal with  
the rate change, leading to more artifacts as the engine prepares to  
play at the new rate.

   I know that Ian is also concerned that having a single playback  
rate will lead to contention when multiple controllers are driving the  
same media engine - making sure that a second controller's play()  
button "does the right thing". This doesn't seem like a very frequent  
use case, but even if is we still have contention because  
defaultPlaybackRate is also mutable.

   We are concerned that people will end up using defaultPlaybackRate  
to do "trick" modes (fast forward, slow motion, etc) because with the  
current model it is the only way to ensure that media starts playing  
at the desired rate while avoiding the artifacts mentioned above. In  
other words, to play at 2x they will set defaultPlaybackRate to 2.0  
and call play(), and then set playbackRate *and* defaultPlaybackRate  
back to 1.0 when they want to resume regular playback.

   We believe that two playback rates are not necessary, and that the  
current model will actually cause problems. Lets get rid of  
defaultPlaybackRate, playbackRate is sufficient.

   Does anyone believe that we should keep the current model?

eric

Received on Saturday, 22 November 2008 01:11:27 UTC