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

Re: Buffered bytes for media elements

From: Jim Jewett <jimjjewett@gmail.com>
Date: Fri, 17 Oct 2008 09:54:56 -0400
Message-ID: <fb6fbf560810170654g33bc8bfal422bce4dc0809202@mail.gmail.com>
To: "HTML WG" <public-html@w3.org>
Cc: eric.carlson@apple.com, "Ian Hickson" <ian@hixie.ch>, "Dave Singer" <singer@apple.com>, jharding@google.com

> How can knowing the number of *bytes*
> available allow you to make a good decision about when sufficient data
> is available to begin playback when you don't know the bit-rate of the
> media file? In other words, how can you know when it is safe to begin
> playback when you have N bytes available but you don't know if playing
> the media file requires 10 K per second or 10 Megs per second?

I'm speculating here, but

Many videos are really a sort of slideshow, without motion.  Even
those with motion often begin with a credits screen that stays static
for several seconds.

If you want to have x seconds buffered, then you want to buffer x
seconds of changing video, not x seconds of the highly-compressible

On a per-video basis, you could just say "well, we need 3x bytes on
this one because of the way it starts."  But if you want to use more
generic scripts, you need some way of telling whether or not those x
seconds were data-heavy.  Specifying bytes rather than seconds is a
fairly good proxy.

If you're thinking of switching to a higher or lower resolution, the
bandwidth limits are normally expressed in (something equivalent to)
bytes/second.  You could do the equivalent with seconds, plus a timer,
plus knowledge of the specific video, but ... it may be simpler to
track bytes.

Received on Friday, 17 October 2008 13:55:30 UTC

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