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

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.

Regards,
Silvia.

Received on Tuesday, 5 January 2010 13:00:52 UTC