W3C home > Mailing lists > Public > public-html@w3.org > March 2011

Re: Change Proposal for ISSUE-147

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 19 Mar 2011 14:07:25 +1100
Message-ID: <AANLkTinrqktSYCqdiOQcMN0A39u3SFBJtzTbzLP+7kBQ@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: public-html@w3.org
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.

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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:10 UTC