Re: Change Proposal for ISSUE-147

Dear Chairs,

I hereby submit a new change proposal to ISSUE-147 in light of recent
discussions and a new understanding by myself of the objections of the
editor. Since IMHO the objections have not been fully analysed and
there has not been sufficient time for all browser vendors to provide
feedback on this new proposal, I would also like to request an
extension of the deadlines so we can have a straw poll before the
chairs make a decision.

Best Regards,
Silvia.


Title
Introduce requestedPlaybackRate/actualPlaybackRate

Counter-Change Proposal for ISSUE-147
playbackrate: undefined behavior when the user agent can't play back
at the requested rate

Summary
The specification should describe what to do if the user agent is
unable to play media at the requested rate. This change proposal
requests that the spec be changed so that the IDL attribute
"playbackRate" is replaced with "requestedPlaybackRate" and
"actualPlaybackRate" to clarify what had been requested and what was
possible to achieve given the browser circumstances. See
http://dev.w3.org/html5/spec/video.html#dom-media-playbackrate.

Rationale
Implementations in browsers vary when an unsupported playback rate is
requested. Since different implementations will have different
capabilities it is important that the media element responds in a
reliable way so that script can detect the issue independent of
whether the change of playback rate was requested through user
interaction with player controls or through script.
There are a number of reasons why a user agent may not be able to play
a resource at the requested speed. For example:
* On low power devices playback is sometimes off-loaded to hardware
that is optimised for forward playback that does not efficiently
support reverse playback.
* Some media formats are not designed to be efficiently played in reverse.
* Setting playbackRate larger than 1.0 for live video will not work.


Details
In section http://dev.w3.org/html5/spec/video.html#dom-media-playbackrate
replace the following text:

"The playbackRate attribute gives the speed at which the media
resource plays, as a multiple of its intrinsic speed. If it is not
equal to the defaultPlaybackRate, then the implication is that the
user is using a feature such as fast forward or slow motion playback.
The attribute is mutable: on getting it must return the last value it
was set to, or 1.0 if it hasn't yet been set; on setting the attribute
must be set to the new value, and the playback must change speed (if
the element is potentially playing)."

with

"The requestedPlaybackRate attribute gives the speed that a user or
author has last requested the speed and playback direction be changed
to. The attribute is mutable: on getting it must return the last value
it was set to, or 1.0 if it hasn't yet been set; on setting the
attribute must be set to the new value, and the UA must attempt to
change speed (if the element is potentially playing).

The actualPlaybackRate attribute gives the speed at which the media
resource actually plays, as a multiple of its intrinsic speed. If it
is not equal to the defaultPlaybackRate, then the implication is that
the user is using a feature such as fast forward or slow motion
playback. The attribute is read-only."

Further changes to other locations in the specification where
"playbackRate" is used have to be made to logically adapt them to
either requestedPlaybackRate or actualPlaybackRate depending on what
they refer to.


Impact

Positive Effects
* Script can reliably detect when an unsupported playback rate has
been requested.
* Different to the earlier change proposal, script can also detect
when the user has attempted to change playback rate through UA
controls, but the browser has not managed to change to that. The
author can in this situation register a onRateChange callback and
determine from requestedPlaybackRate and actualPlaybackRate the
unsuccessful change of playback rate and take evasive action, such as
provide script-controlled changes to currentTime and simulate seeking.
* OnRateChange can actually be used for something useful by Web authors.


Negative Effects
* The IDL attribute playbackRate is removed from the spec, which will
make some existing browser implementations incompatible. However, this
happens basically with all changes that are being made to the spec and
should not inhibit us from improving it to achieve a better spec. By
choosing new names for the new attributes, authors will be able to
deal with this situation.


Conformance Classes Changes
Web browsers and other interactive user agents.

Risks
None. Browsers already vary in this respect.

References
http://dev.w3.org/html5/spec/video.html#dom-media-playbackrate

Received on Thursday, 17 March 2011 19:11:49 UTC