Re: Change Proposal for ISSUE-147

On Thu, 17 Mar 2011, Philip Jägenstedt wrote:
> 
> This CP assumes that the UA knows beforehand which playback rates it can 
> support. Like many things in media, the only way of knowing for sure may 
> be to try it, so how should a UA handle a situation like that?

It also seems like what playback rate is achievable might change in real 
time, either based on changing stream characteristics, or based on 
the CPU load varying. Also, some platforms have a limit to how many 
simultaneous streams they can decode, in which case some streams would be 
decoding at the actual rate (.playbackRate) and some would be decoding at 
zero rate.

What might make sense is to do something like what Silvia proposed, but 
instead of changing the existing API, just adding an API that returns 
current playback metrics. That is, have playbackRate and 
defaultPlaybackRate work as specced now, but add a .metrics object that 
includes amongst other things an .actualPlaybackRate attribute that gives 
the actual result. It would make a lot of sense to have this if we add to 
it the other metrics that browsers are exposing in vendor extensions.

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