W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Should <video> buffer control be tri-state?

From: Robert O'Callahan <robert@ocallahan.org>
Date: Sun, 10 Jan 2010 17:57:38 +1300
Message-ID: <11e306601001092057n5eb50586hc5339b6b08d1e12c@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Eric Carlson <eric.carlson@apple.com>, Kornel <kornel@geekhood.net>, public-html@w3.org
On Sun, Jan 10, 2010 at 5:16 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 1/9/10 1:19 PM, Silvia Pfeiffer wrote:
>> I suggest calling it preload (preload="no", preload="metadata",
>>>> preload="all"?).
>>>>   "all" is a poor choice because it may not be possible for the entire
>>> resource to be stored on the client machine, so you certainly don't want to
>>> preload the entire thing.
>>> eric
>> I agree. Maybe "progressive" is the correct word? (nipped from
>> "progressive streaming", of course)
> What about "playthrough" (as in, keep buffering at least until you would
> fire the canplaythrough event)?

That's really a different feature.

"all" gives you the possibility of seeking anywhere more or less instantly.
It also gives you a higher probability of being able to play through without
stalling, because canplaythrough is an approximation and can be wrong due to
varying network conditions.

I think it would be reasonable to offer preload="no", preload="metadata",
preload="playthrough" and preload="all" with the understanding that due to
resource or policy limits any value (other than "no") is only a hint and the
user agent may not be able to honor it.

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
Received on Sunday, 10 January 2010 04:58:10 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:07 UTC