Re: ISSUE-147: playbackrate-undefined - Straw Poll for Objections *change*

Thanks!

I've added this proposal to the poll and changed the closing date to 
March 5th.

- Sam Ruby

On 03/29/2011 05:23 AM, Philip Jägenstedt wrote:
> On Mon, 28 Mar 2011 22:57:47 +0200, Sam Ruby <rubys@intertwingly.net>
> wrote:
>
>> On 03/28/2011 08:00 AM, Sam Ruby wrote:
>>>
>>> If something is produced in the next 36 hours I would support adding it
>>> to the existing survey and extending the closure date by a corresponding
>>> amount of time.
>>
>> The 3 co-chairs met and agreed that if a new proposal comes in by
>> 11:59pm PDT on the 29th, we will evaluate the proposal and if we find
>> it acceptable we will add it to the existing survey. If we do so, we
>> will also change the closing date from April 4th to somewhere around
>> April 7th, depending on how long it takes for us to evaluate the
>> proposal.
>
> Thanks, here it is:
>
> Summary: Consider inability to play at a given playback rate a hardware
> limitation and don't expose it via a dedicated API
>
> Rationale:
>
> In general, a user agent cannot know if it's possible to play at any
> given rate without actually trying it, as it depends on the size/bitrate
> of the video and available CPU, memory and other hardware resources, all
> of which can change at any time. Consequently, the actual playback rate
> must be exposed asynchronously some time after playbackRate was changed.
> As it happens, the raw metric for determining the actual playback rate
> is already available: currentTime. Working with it is not trivial, but
> entirely possible. Unless web authors request a simpler API and have
> strong use cases for it, we should accept this status quo.
>
> Both Frank Oliver's [1] and Silvia Pfeiffer's [2] change proposals
> claims as a positive effect that "Script can reliably detect when an
> unsupported playbackRate has been requested." Yet, neither suggested API
> would allow scripts to detect the situation in a way that enables
> meaningful use cases. In particular, neither would allow the
> fast-forward button in a scripted UI to be dimmed or removed, as it's
> only possible to detect after the fact that playing at particular rate
> is not supported. At best, the fast-forward button would be
> dimmed/removed after the first time it's used, which has not been
> requested and seems like an obviously flawed UI.
>
> An API that would be useful for scripts would have to expose the
> available playback rates synchronously and without trying to change the
> playback rate. Since it is not possible to expose this information in
> general, simply not adding an API for it is the only reasonable conclusion.
>
> Details:
>
> The behavior when the user agent can't play at the requested rate is
> already quite well defined:
>
> * playbackRate and defaultPlaybackRate reflect whatever value was set.
>
> * currentTime changes at a rate as close to playbackRate as possible.
>
> To clarify the situation for authors, note in "Playing the media
> resource" or "Best practices for authors using media elements" that
> scripts must not assume that setting playbackRate to x causes
> currentTime to advance smoothly at exactly x, as hardware, software or
> format limitations may cause video frames to be dropped, audio to be
> choppy or muted.
>
> Positive effects:
>
> * User agents are encouraged to support arbitrary playback rates rather
> than advertise their inability to do so.
>
> * Web authors are encouraged to make their video players degrade
> gracefully if the exact requested playback rate isn't possible to achieve.
>
> * No premature spec change without understanding the use cases.
>
> Negative effects:
>
> * IE9 has to change.
>
> [1] http://lists.w3.org/Archives/Public/public-html/2011Feb/0113.html
> [2] http://lists.w3.org/Archives/Public/public-html/2011Mar/0357.html
>

Received on Tuesday, 29 March 2011 13:06:05 UTC