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

On Tue, 05 Jan 2010 14:00:00 +0100, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:

> On Tue, Jan 5, 2010 at 8:35 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Tue, 05 Jan 2010 09:43:48 +0100, Scheppe, Kai-Dietrich
>> <k.scheppe@telekom.de> wrote:
>>
>>> Hi,
>>>
>>>> What are the actual use-cases for author control over buffering here?
>>>> The only reasons I can think of are
>>>>
>>>> 1) Improve user experience.
>>>> 2) Conserve server bandwidth.
>>>>
>>>> For (1), is it likely that typical authors will ever be able
>>>> to make a better guess on whether autobuffering is needed
>>>> than implementers?
>>>> Why would this be?  What information would authors have that
>>>> the browser couldn't figure out just as well?  This is all
>>>> keeping in mind that while browser heuristics will fail
>>>> sometimes, so will author use of the autobuffer attribute.
>>>
>>> The question is not whether authors are likely to do something or not.
>>> By not giving them the opportunity in the first place we will certainly
>>> keep them from learning.
>>>
>>> Furthermore, it is not the small time authors that drive usage of
>>> technology, but the big ones, who have a stake in doing it correctly  
>>> and
>>> serve as examples to the others.
>>> Everybody looks at how the "big guys" are doing it.
>>>
>>> As such please do not discount that people are capable of doing things
>>> correctly.
>>>
>>>
>>>> For (2), is a "conserve server bandwidth" feature needed, if
>>>> browsers only ever buffer enough to play through the video at
>>>> worst (i.e., don't buffer the whole thing like Firefox 3.5
>>>> seems to do if autobuffer is set), and usually only do that
>>>> if the user is actually going to play the video, and authors
>>>> who really care can use script hacks?
>>>>
>>>> I'm concerned that autobuffering is too subtle for average
>>>> authors to get right even with only two options, let alone if
>>>> a third is added.
>>>
>>> Perhaps, but then HTML 5 is not exactly setting out to be fool proof  
>>> :-)
>>> If HTML 5 wants to be true to its goals of cleaning up what has been  
>>> done
>>> wrong before, then this is not for the timid.
>>
>> This is a new feature and there is nothing to clean up.
>>
>> I'm really keen to know what precisely the suggested feature is,  
>> because "no
>> autobuffering" and "no buffering" is far too vague for at least me to
>> understand.
>
> To me it means "whatever you do, dear browser, for god's sake do not
> download the full resource. Only download as little as is absolutely
> necessary from the media resource to display that there is a video
> that can be played. Preferably download nothing at all".
>
> It is basically an outcry of a Web author that currently cannot be
> expressed in HTML5 - it is only implicitly assumed. A Web author can
> only hope that this is what a browser will do when he/she doesn't use
> the autobuffer attribute. It is almost like declaring a variable but
> not initialising it and hoping that the compiler will explicitly set
> it to 0, even though the compiler specification doesn't say so.

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". It's possible to add any number of states, but I don't
support adding a third buffering="minimal" until it is shown in a browser
that distinguishes between the first two states (e.g. Firefox 3.5)
actually need a third state. If speccing only two states makes the change
seem pointless, I would tend to agree, but at least it leaves the
possibility of adding more states should they become necessary.

Note: I'm not saying that a "minimal" state will be pointless for all
future, I'm saying that it's better to wait on a proof-of-concept
implementation that does something useful before deciding what to call a
new state and what its conformance requirements should be.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Tuesday, 5 January 2010 16:36:35 UTC