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

On Sat, Jan 2, 2010 at 8:42 PM, 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.
>

Would it not be better to abandon autobuffer, and support a buffer
attribute? With values of buffer="yes" buffer="no" and buffer="auto",
which would be equivalent to how browsers handle no autobuffer now?

The reason I ask this, is I'm going to file a bug if one has not been
filed--not to stop the discussion, but to ensure this important
concern does not fall through the cracks. And if others want to file
the bug instead, I won't -- I mainly just want to ensure this item is
recorded and goes through proper channels.

> Regards,
> Maciej
>

Shelley

Received on Tuesday, 5 January 2010 13:24:03 UTC