This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23929 - <video>: expose the maximum playback rate supported by the server
Summary: <video>: expose the maximum playback rate supported by the server
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-26 22:02 UTC by Ian 'Hixie' Hickson
Modified: 2014-09-26 21:21 UTC (History)
3 users (show)

See Also:

Attachments

Description Ian 'Hixie' Hickson 2013-11-26 22:02:13 UTC 
On Fri, 19 Jul 2013, Brendan Long wrote:
> On Jul 19, 2013 3:14 PM, "Ian Hickson" <ian@hixie.ch> wrote:
> > > 
> > > What if we added a "supportedPlaybackRates" attribute, which holds 
> > > an array of playback rates supported by the server, plus 
> > > (optionally) any rates the user agent can support due to the 
> > > currently buffered data (possibly requiring that the user agent have 
> > > enough data buffered to play at that speed for some amount of time).
> >
> > Wouldn't that be 0.0 .. Infinity, basically?
> 
> I've been thinking about this more, and it seems like the buffered 
> attribute is enough for a JavaScript application to determine for itself 
> if it's safe to play faster. It does seem useful to expose the rates 
> supported by the server though, so an application can realize that it's 
> safe to play at those rates, even if there's not much buffered yet.

On Tue, 10 Sep 2013, Brendan Long wrote:
> For DLNA servers, there's a "playspeed" header. I'm not sure how other
> servers would expose this.
Comment 1 Ian 'Hixie' Hickson 2014-09-26 21:21:39 UTC 
There hasn't been much demand for this, and it's possible to do if you control both the server and Web page anyway. So, punting for now.