Re: Buffered bytes for media elements

If that's the case, then bufferedBytes does seem somewhat redundant - it
would be difficult for a page author to extract much meaning from the
additional precision in the byte ranges vs. the aggregate loaded bytes from
the progress event.

-John

On Fri, Oct 24, 2008 at 3:01 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> I assume that progress events will eventually refer to
> http://www.w3.org/TR/progress-events/
>
> These events have lengthComputable/loaded/total fields by which you can
> track the progress of the download.
>
> Such events will be fired "every 350ms (±200ms) or for every byte
> received, whichever is least frequent" according to the current HTML5
> draft.
>
> Philip
>
> On Tue, 2008-10-21 at 12:23 -0700, John Harding wrote:
> > 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
> >
> >
> >
> --
> Philip Jägenstedt
> Opera Software
>
>