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

>
>>  -----Original Message-----
>>  From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
>>  Behalf Of Dave Singer
>>  Sent: Sunday, October 19, 2008 8:57 PM
>>  To: Eric Carlson; Jim Jewett
>>  Cc: HTML WG; Ian Hickson; jharding@google.com
>>  Subject: Re: Buffered bytes for media elements
>>
>>
>>  Knowing bytes really doesn't help you unless you know how relevant
>>  those bytes are, also.  Are they bytes 'immediately in front of the
>>  playhead'?  You just don't know.  Also, are they 'dense'?  Maybe we
>>  have 200 kb buffered -- but it's all bytes of the video and none of
>>  the audio.  Or it's the first 3 seconds, then there is a 10-second
>>  gap, and then 4 seconds more.  Or, or, or...
>>
>>  We really need to define questions that have a clear semantic as to
>>  what you are trying to do, I think, that can be correctly and
>>  helpfully answered by most or all media systems and for most or all
>>  delivery technologies.
>>
>>  Consider a system which is playing directly from a DVB stream (e.g.
>>  you have a digital radio receiver in your hand-held device).  You
>>  don't need more than a frame or two buffered, as delivery is exactly
>>  real-time and jitter-free.
>>
>>
>>  --
>>  David Singer
>>  Multimedia Standards, Apple Inc.


-- 
David Singer
Multimedia Standards, Apple Inc.

Received on Monday, 20 October 2008 02:54:12 UTC