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

On Sun, 03 Jan 2010 03:42:26 +0100, Maciej Stachowiak <mjs@apple.com>  
wrote:

>
> I'm picking a semi-arbitrary point to fork a new thread.
>
> On Dec 30, 2009, at 9:17 AM, Tab Atkins Jr. wrote:
>
>> On Wed, Dec 30, 2009 at 7:33 AM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> 3. @autobuffer="off" - the web page author cares and believes it would
>>> be a nuisance to the user to autobuffer this video and waste
>>> bandwidth, so the browser doesn't autobuffer - it this case, it may
>>> even make sense to not even try and initialise the decoding pipeline,
>>> but only display the poster frame, if possible (maybe the
>>> X-Content-Duration can help to display the video duration and that's
>>> all that's required?). I'm specifically thinking here about a Web page
>>> that has dozens of videos on it (e.g. as search results or for
>>> browsing a collection). It might not make sense to pre-buffer anything
>>> at all in such a case where playback is highly unlikely.
>>
>> This comes back around to what Philip was saying before - is it really
>> best for the user to treat autobuffer=off any different than no
>> autobuffer at all?  *Will* a browser treat the two differently?  We
>> know that it's obviously often best to not autobuffer by default -
>> this has been established, and the automatic autobuffering that is
>> going on currently in some browsers is a bug.  Once that is fixed,
>> though, is it really worthwhile to do something fully different in
>> your situation 1 and 3?
>
> Buffering by default isn't a clear win or lose - it's a tradeoff. When a  
> page has only a single video that the user is highly likely to want to  
> play, and the user has a good network connection, it's probably best to  
> buffer aggressively, so the user gets a faster response when they choose  
> to play. If a page has many <video> elements, then it's probably best  
> not to buffer aggressively, as the "thundering herd" of multiple videos  
> being buffered will likely swamp their system, and the likelihood of  
> buffering any one would be slow.
>
> In the absence of any explicit attributes for buffer control, a likely  
> good design would be to apply a heuristic. For example: if a page  
> contains only one <video> element, then buffer aggressively. If it  
> contains many, don't buffer any of them. Alternately, one could look at  
> whether a particular video has larger explicit dimensions or appears in  
> a more prominent place on the page. Since an unaware author is most  
> likely not to add any special attributes, it would be nice to apply a  
> heuristic like this when no special buffering-related attribute is  
> present. Let's call this case (A).
>
> This leaves two other cases: (B) author knows a video is very likely to  
> be played, notwithstanding what browser heuristics may guess; in this  
> case he or she adds the "autobuffer" attribute; (C) author knows a video  
> is not that likely to be played, even though it may otherwise appear so  
> to heuristics -- for example, a blog may contain a video in only one  
> posting but the blog author thinks most readers will not play it on the  
> typical visit. In case (B) the browser should do its best to buffer,  
> given bandwidth constraints, and in case (C) it should almost certainly  
> not buffer.
>
> But right now there is no way to distinguish case (C) from case (A). So  
> when autobuffer is omitted, browsers are faced with the choice of either  
> never buffering, even if the omission is solely through lack of  
> awareness, or applying heuristics even when the page author explicitly  
> does not want buffering.
>
> Thus, I think it would be best to add a nobuffer attribute or  
> autobuffer=off or something like that to give a strong hint that a  
> video's full data will not be needed, in the same way that autobuffer  
> hints that the video's full data likely will be needed.

I agree with adding tri-state behavior in some form, although the details  
are still unclear. We must agree that turning buffering off means not even  
touching the network and the exact details of what the UA should do. My  
suggestion:

In the resource fetch algorithm, add a step 1.5 saying that if buffering  
is turned off, fire a stalled event and go to NETWORK_IDLE. Cause the  
algorithm to block until one of a number of things happen, e.g. play() is  
called or .currentPosition is set (maybe). Since this will cause us to  
remain at HAVE_NOTHING, authors must be very aware that duration and  
dimensions will not be available. The spec actually already allows (but  
doesn't require) doing this, but it is really going to cause compatibility  
issues if some browsers do this slightly differently, so I think we need  
the spec to be explicit.

If we support this, I think we should just drop autobuffer, possibly  
keeping it in conformance requirements form browsers if we think there is  
enough existing content that would break by removing it (I don't think  
so). Replace it with a single multi-state attribute like "buffering"  
instead. Values "none", "auto" (the default) and "full", or similar.  
Unless there's a cleaner way to represent the semantics "this is  
(un)likely to be used"....

For <video>, possibly it should be a validation error to use  
buffering="none" without a poster image, as this would make the element  
quite useless (in the absence of CSS doing the same as poster) .

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Sunday, 3 January 2010 11:37:24 UTC