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

Working Group Decision on ISSUE-147 playbackrate-undefined

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 08 Apr 2011 14:15:18 -0400
Message-ID: <4D9F50B6.2000807@intertwingly.net>
To: HTML WG <public-html@w3.org>
The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.

*** Question before the Working Group ***

There is a basic disagreement in the group as to whether or not there
is a need to enable scripts to reliably detect when an unsupported
playbackRate has been requested, and if so, how such information should
best be exposed to the scripts.  The result was an issue, three change
proposals, and a straw poll for objections:


Additionally, one of the authors of a Change Proposal indicated during
the course of the survey that they were willing to withdraw the


As we have no way of knowing whether or not this proposal has other
supporters, this offer to withdraw has no affect.

== Uncontested observations:

With three proposals, we don't generally expect much to be untested.
Unsurprisingly the only thing we find of general agreement is as

   Browsers already vary in this respect

This observation was not decisive.  There were people who supported
different proposals even after taking this fact into consideration.
The fact that this were acknowledged up front was appreciated.

=== Evaluation of Objections

While we have three proposals, we have a low number of expressed
objections, so the best way forward is simply via brute force

The first proposal is to "describe what to do if the user agent is
unable to play media at the requested rate".  The first objection to
that proposal is from an implementor:

   As an implementor of the <video> element, I don't think we can
   implement this in general; we won't know whether we can maintain a
   given playback rate until we try to play back at that rate. Even
   then, whether we can sustain the rate will vary from moment to

While there were additional objections made against this proposal, this
clearly is a very strong objection.  We can then proceed onto the next
proposal to see if it attracts a stronger objection.

The next proposal is to "introduce requestedPlaybackRate/
actualPlaybackRate to the HTML5 spec".  Stated objections include:

   This proposal seems under-specified. In particular it is unclear how
   the "actualPlaybackRate" should be computed, in particular what time
   window should be used. Given that actualPlaybackRate can vary from
   moment to moment, it's unclear how scripts should use it. And
   actualPlaybackRate may not be adequate to reflect the quality of the
   user experience; e.g. if the UA plays a the requested playback rate,
   but only at one frame per second, should we report actualPlaybackRate
   == requestedPlaybackRate and let the script assume everything is OK?


   No use case is given for script to be able to access the
   requestedPlaybackRate after attempting to set the playback rate.

While these are strong objections, they are not as strong as the
objection to specifying behavior that at least one vendor can't

Finally, we have the Change Proposal to "consider the inability to play
at a given playback rate a hardware limitation and not expose it via a
dedicated API".

This proposal attracted no objections from the survey.  From the
positive effects of the other proposals, we infer the following

   Script can't reliably detect when an unsupported playbackRate has
   been requested

Lacking a concrete use case, this objection was not found to be strong.
It certainly isn't as strong as either an objection based on
under-specification or based on lack of implementability.

Additionally we have objections on the basis that it would break the
ability of Web apps to be able to tell when the user has switched to
"fast forward" mode, would be incompatible with a situation in which
the user agent _can_ apply the requested rate for some part of the
media but not all of it, would have the UA ignore requests that could
partially be satisfied, and the fact that it is only possible after the
detect after the fact that a particular rate is not supported.  The
strength of these claims were not evaluated further as they could only
further support the "Consider inability to play at a given playback
rate a hardware  limitation and don't expose it via a dedicated API"
Change Proposal and thus were not needed in order to identify the
proposal that draws the weakest objections.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the "Consider inability
to play at a given playback rate a hardware limitation and don't
expose it via a dedicated API" Change Proposal for ISSUE-147:


Of the Change Proposals before us, this one has drawn the weaker

== Next Steps ==

Bug 10837 is to be REOPENED and marked as WGDecision.

Since the prevailing Change Proposal does call for a spec change, the
editor is hereby directed to make the changes in accordance to the
change proposal.  Once those changes are complete ISSUE-147 is to be
marked as CLOSED.

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time.  Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition

== Revisiting this Issue ==

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Use cases which require scripts to be able to determine the
   playbackRate of a given video.
Received on Friday, 8 April 2011 18:15:43 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:36 UTC