W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2013

Re: [whatwg] Proposal: Media element - add attributes for discovery of playback rate support

From: Eric Carlson <eric.carlson@apple.com>
Date: Thu, 18 Jul 2013 14:17:08 -0700
Message-id: <860226D3-29AC-4709-BB65-DEC36CF7C20E@apple.com>
To: Brendan Long <self@brendanlong.com>
Cc: whatwg@lists.whatwg.org

On Jul 18, 2013, at 1:13 PM, Brendan Long <self@brendanlong.com> wrote:

> On 07/18/2013 06:54 AM, John Mellor wrote:
>> If the user is speeding up playback to improve their productivity (spend
>> less time watching e.g. a lecture), then they may well be willing to wait
>> until enough of the video is buffered, since they can do something else in
>> the meantime.
>> 
>> For example by spending 30m buffering the first half of a 1 hour live
>> stream, the user could then watch the whole hour at double speed.
> This is how DVR's work with live TV and people seem to like it (well,
> they like it more than not being able to fast-forward at all..).

  And it works because a DVR has lots of disk space. This is not the case with all devices that support the media element.

 Even a DVR, however, won't always let you change the playback speed. For example it isn't possible to play at greater than 1x past the current time when watching a live stream. If I am watching a live stream and I try to play past the end of the buffered video, my DVR drops back to 1x and won't let me change the speed. It doesn't automatically pause and buffer for a while so it can play at a faster rate.

  It isn't always possible to play a media stream at an arbitrary speed. It is foolish to pretend otherwise as the current spec does. 

eric
Received on Thursday, 18 July 2013 21:17:32 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:03 UTC