W3C home > Mailing lists > Public > public-html@w3.org > October 2008

Re: Buffered bytes for media elements

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 14 Oct 2008 01:06:48 +0000 (UTC)
To: Dave Singer <singer@apple.com>
Cc: public-html@w3.org, John Harding <jharding@google.com>
Message-ID: <Pine.LNX.4.62.0810140101020.1237@hixie.dreamhostps.com>

On Thu, 18 Sep 2008, Dave Singer wrote:
> <http://www.w3.org/html/wg/html5/#media>
> From the spec.:
# The bufferedBytes attribute must return a static normalized  object that
# represents the ranges of the media resource, if any, that the user agent 
# has buffered, at the time the attribute is evaluated.
# The totalBytes attribute must return the length of the media resource, 
# in bytes, if it is known and finite. If it is not known, is infinite 
# (e.g. streaming radio), or if no media data is available, the attribute 
# must return 0.
> We don't think these are well-defined for a whole host of cases:
> -- live streams
> -- SMIL files that reference several media files
> -- media files like MOV and MP4 that reference media files, or even MP4 or MOV
> files that are not interleaved in time order
> -- streaming protocols in general (non-buffering)
> It's by no means clear to us what these attributes are for -- what the use
> cases are.  We think they should be removed, or supported with use cases that
> are able to show why they are useful despite all these cases where either
> their meaning or utility (or both) are unclear...

These attributes were added primarily in response to a request from 
YouTube, if I recall correctly. The problem they solve is that there can 
be a great difference between the amount of time buffered and the number 
of bytes buffered, and a clever author would find information about the 
bytes buffered to be far more useful than the amount of time available.

I agree that for many use cases, these are underdefined. I would be 
interesting in hearing feedback on what would be the best way to resolve 
this problem. If we remove the feature altogether, we should have an 
alternative of some kind, though.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 14 October 2008 01:07:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC