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

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 06 Jan 2010 11:47:58 +0100
To: "Henri Sivonen" <hsivonen@iki.fi>
Cc: public-html@w3.org
Message-ID: <op.u53xl8plsr6mfa@worf>
On Wed, 06 Jan 2010 11:07:27 +0100, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Jan 5, 2010, at 18:35, Philip Jägenstedt wrote:
>> I support replacing the autobuffer attribute with a buffering attribute,
>> Absence of autobuffer is replaced with buffering="auto" (um, this
>> reversion *will* confuse, but oh well) while its presence is replaced  
>> with
>> buffering="full".
> Would you consider a new buffering attribute better than using the  
> existing attributes as follows?
>  * If the autobuffer attribute is present, select "full buffering  
> strategy" and abort these steps.
>  * If the poster attribute is present, select "no buffering strategy"  
> and abort these steps.
>  * Otherwise, select "partial buffering strategy".
> Where the strategies are as follows:
> "full buffering strategy": Buffer the video fully (or less if fully  
> buffering would hit cache size limits).
> "no buffering strategy": Don't request any piece of the video at all  
> before the video is played.
> "partial buffering strategy": Request enough of the video to be able to  
> decode the first frame and (format permitting) discover the duration.

That was certainly my original intention and on the surface of things a  
nice solution, but:

1. the "no buffering" strategy won't be possible to use for <audio>

2. it would be easy to activate the "no buffering" strategy by accident  
simply by using the poster attribute, which isn't that great because it  
will break scripts that rely on videoWidth/videoHeight or duration being  

The "no buffering" strategy is a bit risky, especially if not all browsers  
implement it at the same time, so if it should exist it ought to be opt-in.

Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 6 January 2010 10:48:38 UTC

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