Re: Change Proposal for ISSUE-147

On Fri, Mar 18, 2011 at 7:39 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Thu, 17 Mar 2011 21:37:27 +0100, Ian Hickson <ian@hixie.ch> 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.
>
> In principle, this seems OK, if a bit unnecessary. We already have the raw
> snapshot metric for determining playback speed: currentTime. Would
> actualPlaybackRate be the derivate of that over a defined period of time?
>
> Anyway, it's not at all clear to me what scripts would actually do with this
> information. Tell the users that their browsers sucks?

Maybe a script author could set currentTime to future (past) times to
simulate changes of the playbackRate? I've not experimented with
something like that, but it sounds do-able given the data has already
been downloaded.

Silvia.

Received on Saturday, 19 March 2011 03:08:18 UTC