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

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

The survey actually closes on at midnight ET on April 5th:
http://www.w3.org/2002/09/wbs/40318/issue-147-objection-poll/ 

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Sam Ruby
Sent: Tuesday, March 29, 2011 9:06 AM
To: Philip Jägenstedt
Cc: public-html@w3.org
Subject: 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 14:17:27 UTC