Re: Buffered bytes for media elements

The primary purpose, from my point of view, was to enable the page author to
make its own determinations about download progress and when playback can
start, independent of the user agent.  Yes, this requires knowledge about
the actual contents of the video, but in a scenario such as YouTube, where
the page author also controls production of the video, this is quite
reasonable.  As I mentioned earlier, the user agent's determination of "can
play through" does not always correspond to the ideal time for playback to
begin.

However, it's unlikely that this would be done on the basis of specific,
non-contiguous byte ranges - if there's a reasonable mechanism for the page
author to track the total download progress (in addition to the
bufferingRate), that would be sufficient.  The current spec I'm looking at
doesn't provide any detail about progress events, either frequency or what
data is available with them.

-John

On Mon, Oct 20, 2008 at 7:05 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> Hi,
>
> I would like to see either a clear use case for bufferedBytes or for it
> to be removed. At the very least, it's a non-zero amount of work to
> implement and it would be nice to know what it is intended for. The
> bufferingRate should tell you the current download rate and the total
> amount downloaded would also be given in progress events (although as a
> sum, not ranges). Perhaps if the actual problem that this is supposed to
> address is made more clear, a better solution can be found.
>
> Philip
>
> On Mon, 2008-10-20 at 08:27 -0400, Justin James wrote:
> > > -----Original Message-----
> > > From: Dave Singer [mailto:singer@apple.com]
> > > Sent: Sunday, October 19, 2008 10:53 PM
> > > To: Justin James; 'Eric Carlson'; 'Jim Jewett'
> > > Cc: 'HTML WG'; 'Ian Hickson'; jharding@google.com
> > > Subject: RE: Buffered bytes for media elements
> > >
> > > At 22:47  -0400 19/10/08, Justin James wrote:
> > > >Why can't we just have both?
> > > >
> > > >J.Ja
> > >
> > > Because we don't want parts of the specification that have so many
> > > holes?
> > >
> > > Heres another one:  if I have loaded 20K of a file, but 10K of that
> > > is not actual media data (maybe it's metadata, maybe not used), do I
> > > report 10K or 20K as the buffered bytes?  If I want to know how much
> > > memory is being used for buffering, 20K is the right answer.  If I
> > > want to know how much data is relevant to my playback, 10K is the
> > > right answer...
> >
> > I agree that all of the questions we've seen on this list so far make it
> > look like using bytes buffered is not a good design decision. I certainly
> > see no reason to use it! At the same time, I don't see how exposing the
> > information at the level that we are concerned about would significantly
> > harm the spec, so long as we include the significantly much more useful
> > "time buffered" number as well. It's like offering the ability to change
> the
> > direction of text, without it being tied to the language being used...
> sure,
> > there should never be a good reason for me to have the Roman alphabet
> going
> > right-to-left, but that doesn't mean that 1 site in a zillion would have
> a
> > good usage for it, and including the functionality is fairly easy (much
> > easier for bytes buffered that RTL text...). :)
> >
> > J.Ja
> >
> --
> Philip Jägenstedt
> Opera Software
>
>