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

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

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