Re: Change Proposal for ISSUE-147

Hi Frank,

In your proposal: if the value of playbackrate is set through a user
interaction through, e.g. controls or the context menu - how does
script detect that there has been a request to change it, but the UA
wasn't able to change it?

Silvia.


On Fri, Mar 18, 2011 at 5:14 AM, Frank Olivier
<Frank.Olivier@microsoft.com> wrote:
> Well, we prefer the proposal that we've made and this is the behavior we implemented in Internet Explorer 9.
> In general I think we're trying to document the behavior people are implementing. As other implementers implement this, they can either follow this proposal or raise a last call issue to discuss their implementation concerns.
>
> Thanks
> Frank
>
> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Thursday, March 17, 2011 12:26 AM
> To: Silvia Pfeiffer
> Cc: Frank Olivier; HTML WG (public-html@w3.org)
> Subject: Re: Change Proposal for ISSUE-147
>
> On Thu, 17 Mar 2011, Silvia Pfeiffer wrote:
>> >
>> > Why would we require that browsers decide whether or not they can do
>> > a good enough job of going at the requested rate and force them to
>> > change the playbackRate accordingly?
>> >
>> > Would reporting the playback quality (e.g. number of frames rendered
>> > over the past second of playback as a fraction of the number of
>> > frames that would ideally have been rendered during that same
>> > period) be an acceptable alternative solution?
>>
>> Hmm, I regard the rendered frames as a statistic of video quality -
>> maybe the audio displayed properly in that time, but video frames had
>> to be dropped to be played, either because of network issues or
>> because the CPU wasn't fast enough. This is different to not
>> supporting the playback rate.
>>
>> Maybe it's better to make a differentiation explicit on playbackRate, such as:
>> * defaultPlaybackRate - continues to be the recommended playback rate
>> for the video
>> * requestedPlaybackRate - is the rate that the author/user requested
>> it to be played back
>> * actualPlaybackRate - is the actual rate at which the browser is
>> managing to play it back (read-only)
>
> Something like that would work too, sure. The idea being that the author can get information from the UA about the actual results the UA is succeeding in providing, while the UA has the instructions from the author (as it does today) regarding the rate it _should_ be playing at.
>
> Frank, would something like that work for you?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>

Received on Thursday, 17 March 2011 18:26:38 UTC