- From: John Harding <jharding@google.com>
- Date: Tue, 28 Oct 2008 08:24:11 -0700
- To: "Philip Jägenstedt" <philipj@opera.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>
- Message-ID: <37307eff0810280824i4a045b23pf57d00dc9bbbc3ba@mail.gmail.com>
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 > >
Received on Tuesday, 28 October 2008 15:24:50 UTC