W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: bufferingThrottled and bufferingRate

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 20 Feb 2009 05:37:31 +0000 (UTC)
To: Eric Carlson <eric.carlson@apple.com>, Philip Jägenstedt <philipj@opera.com>, Chris Double <cdouble@mozilla.com>
Cc: HTML WG <public-html@w3.org>, Jeremy Doig <jeremydo@google.com>
Message-ID: <Pine.LNX.4.62.0902200433150.6209@hixie.dreamhostps.com>
On Wed, 19 Nov 2008, Eric Carlson wrote:
>   Can someone explain why we need the "bufferingRate" and 
> "bufferingThrottled" media element attributes?
>   I believe the rational is that scripts might want to attempt to 
> implement bandwidth management, but I don't think that is a realistic 
> goal. Just knowing that a user has "unused" network bandwidth doesn't 
> mean they will be able to decode and display a higher bit-rate stream, 
> they also need to have "unused" cycles on the CPU/GPU - something a 
> script can't detect.
>   Is there another use case for these attributes? Does anyone think they 
> are necessary for the first version of the spec?

On Thu, 20 Nov 2008, Philip Jägenstedt wrote:
> I would agree that at least bufferingThrottled no longer serves any 
> purpose. Since NETWORK_IDLE is now used only "when a media element's 
> download has been suspended" checking for this state should be enough.
> As for bufferingRate, I would support removing it because it isn't 
> obvious that it is of any use now that the bufferedBytes attribute is 
> gone. Tracking the buffered and seekable TimeRanges would seem a much 
> better way of determining by script when to pause and play. Note however 
> that removing bufferingRate doesn't hide the information about the 
> servers bandwidth -- a script could still track progress events if they 
> really wanted to.

On Thu, 20 Nov 2008, Chris Double wrote:
> I agree with Philip and Eric. If they need to be kept it would be useful 
> to see an example of how they would be used.

The idea is that if the site can dynamically change the video data to have 
a different bitrate, the site can use bufferingRate to get information on 
what the current rate is. But that wouldn't work if the user agent is 
throttling (without pausing) the download, since the result would just be 
poorer quality video when all that the user wanted was to wait a bit 
before the file was loaded. That is what the bufferingThrottled attribute 
is for, it allows the script to check to see if the rate is "real" or not.

Does that make sense?

If there's still a desire that they be removed, I can definitely remove 
them for this version.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 20 February 2009 05:38:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC