- From: Mark Watson <watsonm@netflix.com>
- Date: Fri, 18 Mar 2011 08:18:25 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: Philip Jägenstedt <philipj@opera.com>, "public-html@w3.org" <public-html@w3.org>
Another possibility would be to define an event fired when the playback rate changes, for example when you are playing at >1.0 and hit the leading edge of a live stream, then playback rate should probably drop to 1.0 (equally, you can be playing at <1.0 and hit the "back" of an availability window for a live stream, meaning again you should switch to 1.0). ...Mark On Mar 17, 2011, at 1:37 PM, Ian Hickson wrote: > 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. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 18 March 2011 15:18:59 UTC