Re: Buffered bytes for media elements

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

Received on Friday, 24 October 2008 10:03:15 UTC