Re: Change Proposal for ISSUE-147

On Sat, 19 Mar 2011, David Singer wrote:
> 
> So, if 
> a) when I 'set' the rate, it actually sets to what can be supported (closest equivalent rate)
> b) rate-changed is posted when it actually changes
> 
> I can achieve these two, right?  Do I need the engine to remember what I asked for?

You don't, but the other controllers do. That's the reason we expose all 
the states and events: so that multiple people (most notably the page 
author and the UA implementor) can both write controllers independently 
and have them consistently and simultaneously interoperate.

If you set the rate in one controller, but the attribute only gets set to 
the best achievable rate or the actual rate or some other such compromise 
rate, the other controller wouldn't be able to distinguish the rate 
changing due to the user hitting "fast-forward 8x" or the browser giving 
up on trying to achieve the previously set rate.


> > Also useful would be to find out the supporting range of playback 
> > speeds in advance, so that fast forward/rewind icons could be dimmed 
> > when those features are not supported.
> 
> Nice to have, for sure, but sometimes the answer will be 'maybe', or contextual:
> a) if I have to ask a server, I don't know until I ask

If the server has to be asked, then we can't really make the attribute 
always reflect the possible rate (as opposed to the set rate).


> b) if it depends on where you are; if you have a buffer of a live 
> signal, as Ian suggests, and you are in the middle of it, for sure, you 
> can fast forward; you can't if you're at the 'now' end of it. ...

Or indeed the buffer of any signal, all that matters in this context is 
whether the rate of data reception is lower than the playback rate.

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

Received on Saturday, 19 March 2011 15:46:36 UTC