Re: Change Proposal for ISSUE-147

On Thu, Mar 17, 2011 at 12:17 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, Feb 4, 2011 at 7:23 PM, Frank Olivier
> <Frank.Olivier@microsoft.com> wrote:
>>
>> 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.
>
> There are lots of things that limited hardware can't handle; we have a
> general "hardware limitations" clause for this.
>
>
>> . Some media formats are not designed to be efficiently played in reverse.
>
> HTML isn't designed to be efficiently rendered either, but we don't
> make that optional. :-)
>
>
>> . Setting playbackRate larger than 1.0 for live video will not work.
>
> Sure it will, so long as the playhead is far enough back that there is
> buffered content to play.
>
>
> We discussed this in #whatwg earlier today, and it was suggested that
> there aren't many use cases for playbackRate in the first place, so
> that it not working wasn't a big deal. Is that true? If so, would it
> be acceptable to just remove the feature entirely rather than
> essentially making it optional? In general optional features are an
> interoperability nightmare, so if we could avoid making this optional,
> it would be much better IMHO.

Out of curiosity, I went to check out the conversation
http://krijnhoetmer.nl/irc-logs/whatwg/20110316#l-776

I always considered the main use case for playbackRate to be fast
forward and fast rewind without actually jumping. Every hardware media
player supports fast forward and rewind, and most software players
that I know do it, too. Is that now not regarded as an important use
case on the Web any more? Is it because seeking can be done by
grabbing the playback position indicator and scrubbing over the video
(which continues to display decoded frames)?

One use case that comes to mind is that vision-impaired people can
actually deal with much higher playback rates than sighed users. They
would certainly be able to make use of such a functionality to much
fast scan the content of an audio or video resource, e.g. listen to a
podcast in high-speed.

Right now, none of the browsers FAIK has a control for
increasing/decreasing playback rate. If there are no plans of
implementation,that may indeed be reason enough to drop the features.
But I believe, even if it's hard to implement, it should continue to
be part of the spec such that it can be implemented by browsers when
the software has improved and allows for it.

Cheers,
Silvia.

Received on Thursday, 17 March 2011 01:48:39 UTC