- From: Kevin Calhoun <kcalhoun@apple.com>
- Date: Fri, 2 Nov 2007 11:20:57 -0700
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
Received on Friday, 2 November 2007 11:20:57 UTC