[Bug 10837] playbackrate: undefined behavior when the user agent can't play back at the requested rate

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10837

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #4 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-10-12 07:13:44 UTC ---
(In reply to comment #3)
> there are cases where the user agent will be unable to change the playbackrate
> - for example, the user agent may be playing a live stream

When playing a live stream, either the browser has a local buffer or it does
not. If it does, then playing backwards is fine (at the worst case, just seek
back frame by frame). If it does not, then the "earliest possible position"
will equal the current playback position and a playback rate that is less than
the live rate will simply result in the browser continuously seeking forward to
keep up with the live stream. In either case, this is already well-defined in
the spec.


> the user agent may be unable to play media backwards (due to limitation of the media format - no
> keyframes) / at a high rate (limitation in hardware) - and 'faking' a playback
> rate with seeking behavior is not a viable alternative.

It's always viable -- in the worst case, you show the current frame then keep
going backwards without showing anything (just moving the playback head on the
seek bar) and then finally show the first frame. This is entirely a quality of
implementation issue. Browsers that can decode such a stream and buffer it in a
way that enables arbitrary seeking will be more usable and more competitive
than browsers that can't.


> The author should be able to determine that the user agent is not doing the
> 'true' requested playback rate.

If the problem is that the media doesn't support going backwards due to a lack
of keyframes and due to a lack of implementations that can work around this
limitation, then it's highly unlikely that the author will attempt to play the
media data backwards in the first place.

However, if the browser is faking it by seeking then it'll be quite clear: the
browser will have fired a "seeking" event and then will not fire a "seeked"
event, and the playback position will not be moving.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The spec already handles all the described cases.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 12 October 2010 07:13:46 UTC