Re: [whatwg] HTMLMediaElement buffered/bufferedBytes
On Tue, 10 Jun 2008, Philip J�genstedt wrote: The name of the buffered/bufferedBytes attributes imply that these ranges are buffered on disk or in memory, so that they will not have to be re-downloaded. However, the description reads the ranges of the media resource, if any, that the user agent has downloaded, at the time the attribute is evaluated. I would suggest that buffered/bufferedBytes be taken to mean exactly what they sound like by changing the description to something like: [s/downloaded/buffered/] [allow unbuffering] Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTMLMediaElement buffered/bufferedBytes
Hi, I'm currently implementing more of audio and video (in Opera) and will probably have quite a lot of questions/comments during the coming months. If this is not the best place for such discussion, please point out where I need to be. Today's issue: The name of the buffered/bufferedBytes attributes imply that these ranges are buffered on disk or in memory, so that they will not have to be re-downloaded. However, the description reads the ranges of the media resource, if any, that the user agent has downloaded, at the time the attribute is evaluated. This is not the same things, as we will not be able to buffer large files on memory-limited devices. Instead, we might only buffer 1 MB of data around the current playback point, or some other scheme. I would suggest that buffered/bufferedBytes be taken to mean exactly what they sound like by changing the description to something like: (differences marked *like this*) The buffered attribute must return a static normalized TimeRanges object that represents the ranges of the media resource, if any, that the user agent has *buffered*, at the time the attribute is evaluated. Note: Typically this will be a single range anchored at the zero point, but if, e.g. the user agent uses HTTP range requests in response to seeking, then there could be multiple ranges. *There is no guarantee that all buffered ranges will remain buffered, due to storage/memory constraints or other reasons.* The intention is that only ranges which are actually internally buffered should be exposed in the buffered/bufferedBytes ranges, whereas the current phrasing implies that all ranges which have at some point been downloaded/buffered should be included. Admittedly, this makes the attributes useless for determining how much of the resource has been downloaded, but if this is needed I might suggest the attributes downloaded/downloadedBytes instead. The usefulness of the buffered attribute (in my current interpretation) is not obvious to me at all, I would appreciate some use cases if possible. -- Philip Jägenstedt Opera Software
Re: [whatwg] HTMLMediaElement buffered/bufferedBytes
I think this all makes sense. +1 from me. Cheers, Silvia. On Tue, Jun 10, 2008 at 8:24 PM, Philip Jägenstedt [EMAIL PROTECTED] wrote: Hi, I'm currently implementing more of audio and video (in Opera) and will probably have quite a lot of questions/comments during the coming months. If this is not the best place for such discussion, please point out where I need to be. Today's issue: The name of the buffered/bufferedBytes attributes imply that these ranges are buffered on disk or in memory, so that they will not have to be re-downloaded. However, the description reads the ranges of the media resource, if any, that the user agent has downloaded, at the time the attribute is evaluated. This is not the same things, as we will not be able to buffer large files on memory-limited devices. Instead, we might only buffer 1 MB of data around the current playback point, or some other scheme. I would suggest that buffered/bufferedBytes be taken to mean exactly what they sound like by changing the description to something like: (differences marked *like this*) The buffered attribute must return a static normalized TimeRanges object that represents the ranges of the media resource, if any, that the user agent has *buffered*, at the time the attribute is evaluated. Note: Typically this will be a single range anchored at the zero point, but if, e.g. the user agent uses HTTP range requests in response to seeking, then there could be multiple ranges. *There is no guarantee that all buffered ranges will remain buffered, due to storage/memory constraints or other reasons.* The intention is that only ranges which are actually internally buffered should be exposed in the buffered/bufferedBytes ranges, whereas the current phrasing implies that all ranges which have at some point been downloaded/buffered should be included. Admittedly, this makes the attributes useless for determining how much of the resource has been downloaded, but if this is needed I might suggest the attributes downloaded/downloadedBytes instead. The usefulness of the buffered attribute (in my current interpretation) is not obvious to me at all, I would appreciate some use cases if possible. -- Philip Jägenstedt Opera Software
