Re: HTMLMediaElement defaultPlaybackRate and playbackRate

On Fri, 21 Nov 2008, Eric Carlson wrote:
> 
> 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.

Interesting point. I've changed play() to not reset the playbackRate.


> 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.

We need the two otherwise there's no way for controllers to cooperate when 
doing fast-forward over a resource that is playing at an accelerated rate. 
It's the same as muted vs volume, except that defaultPlaybackRate doesn't 
really _do_ anything now (except during the load() method).

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

Received on Monday, 1 December 2008 07:55:17 UTC