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

RE: Buffered bytes for media elements

From: Justin James <j_james@mindspring.com>
Date: Mon, 20 Oct 2008 08:27:29 -0400
To: "'Dave Singer'" <singer@apple.com>, "'Eric Carlson'" <eric.carlson@apple.com>, "'Jim Jewett'" <jimjjewett@gmail.com>
Cc: "'HTML WG'" <public-html@w3.org>, "'Ian Hickson'" <ian@hixie.ch>, <jharding@google.com>
Message-ID: <032901c932af$37edd990$a7c98cb0$@com>

> -----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...). :)

Received on Monday, 20 October 2008 12:28:17 UTC

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