[whatwg] media element playback rates

On Mon, 5 Nov 2007, Kevin Calhoun wrote:
> > 
> > How far in advance? Would passing an argument to play() satisfy this? 
> > (i.e. can it be immediately before playback begins, or does it have to 
> > be measurably earlier?)
> 
> Indefinitely earlier -- allowing the media to pass through arbitrary 
> states as needed before playback at the requested rate is ready.

Ok let me phrase this differently -- given a UI that allows fast forward 
and fast rewind from a stopped position, in what order should the calls be 
made to the API in an ideal API to give the underlying video system the 
best chance at skip-free playback?


> > > In the alternative model Dave described, the same operations you 
> > > enumerated are also readily performed as below [...]
> > 
> > With the proposal, I don't see how you can set the speed in one 
> > controller and then have another controller do fast-forward and then 
> > have the first controller resume play again, which is a design 
> > requirement for this API.
> 
> Multiple controllers of the same media, hmmm. Can you say more about 
> these requirements?

Any scripted <video> element always has at least two controllers -- the 
page's <video> UI, and the browser's. Both need to be able to stay in sync 
with everything so as to expose an interface consistent with the current 
state of the playback, as well as being able to expose all their features 
in a way that predictably works.

You may sometimes find multiple controllers, e.g. if an author mixes and 
matches different JS components to make a custom UI, and some of the 
components have overlapping scope.

(This mostly came from discussions with Apple, by the way, though I do 
agree with the requirement.)

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

Received on Monday, 5 November 2007 08:00:13 UTC