Re: bufferingThrottled and bufferingRate

On Fri, 20 Feb 2009, Jeremy Doig wrote:
> On Thu, Feb 19, 2009 at 9:37 PM, Ian Hickson <ian@hixie.ch> wrote:
> > 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.
>
> ok to drop them for v1

I've dropped them (actually, just commented them out) for now.


> but still wish we could have droppedframecount

Yup, that's pretty high on the list of features for the next version.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'