RE: Change Proposal for ISSUE-147

"Right now, none of the browsers FAIK has a control for increasing/decreasing playback rate."
Internet Explorer 9 has this; programmatic control and via the <video controls> context menu.

"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."
I also believe that it should continue to be part of the spec. We did not find it hard to implement; we also added de-chipmunking to improve audio quality in this scenario. As Silvia points out, users sometimes want to consume content at a faster-than-real-time rate. 

>> . 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.
Sure, but what happens when you play through the buffered content and get to (effectively) a live feed? The author should be able to determine that effective playback rate is now 1.0 in this outcome - and setting to >1.0 should not work.

-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: Wednesday, March 16, 2011 6:48 PM
To: Ian Hickson
Cc: Frank Olivier; HTML WG (public-html@w3.org)
Subject: 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 02:33:21 UTC