- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 1 Dec 2008 07:54:42 +0000 (UTC)
- To: Eric Carlson <eric.carlson@apple.com>
- Cc: HTML WG <public-html@w3.org>
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