- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 24 Oct 2008 12:01:47 +0200
- To: John Harding <jharding@google.com>
- Cc: Justin James <j_james@mindspring.com>, Dave Singer <singer@apple.com>, Eric Carlson <eric.carlson@apple.com>, Jim Jewett <jimjjewett@gmail.com>, HTML WG <public-html@w3.org>, Ian Hickson <ian@hixie.ch>
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