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

On Sun, 03 Jan 2010 21:43:23 +0100, Aryeh Gregor  
<Simetrical+w3c@gmail.com> wrote:

> On Sat, Jan 2, 2010 at 9:42 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> 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.
>
> But authors don't just leave off attributes they don't know about,
> they also add attributes they don't understand, copy-pasted from some
> different context.  While a lot of authors will inadvertently leave
> out autobuffer, some will inadvertently include it, too (and that's
> much harder for users to notice).  Browsers can't rely on any markup
> being correct when its effect is so subtle.
>
> With a declarative tri-state control, I'd expect a situation something  
> like:
>
> * Well-written sites will mostly force autobuffering one way or
> another, unless browsers develop excellent heuristics.  Authors assume
> they know better than browsers.  Thus these sites will use the third
> state rarely if ever.
> * Poorly-written sites will copy from tutorials and other sites and
> get a random value for autobuffer.  What would be best for these sites
> is having no markup-based control here are all, or only weak
> markup-based control, so browsers can do the right thing regardless.
>
> My conclusion is that authors should be given limited control over
> autobuffering from markup -- the autobuffer attribute should be a weak
> hint.  Markup features tend to be copy-pasted, and most authors won't
> spot subtle distinctions like whether the video is autobuffered.
>
> Now, if authors really really want to force autobuffering off no
> matter what, they can already do that through script hacks.  If this
> happens a lot, even after existing WebKit is long retired, that will
> be a clue that authors really want better autobuffering control.  In
> the meantime, I think we shouldn't add an easier way to force
> autobuffering off no matter what, because many authors will
> accidentally misuse it.
>
> The long-term goal should be that authors don't have to worry about
> this, IMO, any more than they have to worry about explicitly telling
> browsers whether to fetch images in stylesheets before they're used.
>
> On Sun, Jan 3, 2010 at 1:47 AM, Robert O'Callahan <robert@ocallahan.org>  
> wrote:
>> The performance effect is very noticeable, and if your controls UI  
>> shows the
>> buffer state, it's quite obvious what's going on.
>
> The performance effect will typically be nonexistent when you're
> testing, because you're probably reloading the same page with the same
> video repeatedly as you make changes.  The video will thus remain
> buffered no matter what.  Also, most developers just try to get things
> working, and are going to be tweaking the layout and so on without
> paying attention to performance.
>
> So you'd have to wait for user complaints.  In practice, only a tiny
> fraction of users complain about even serious problems with sites.  So
> even quite large sites would wind up with incorrect video buffering if
> any kind of hard control were made available from markup.
>
> On Sun, Jan 3, 2010 at 6:37 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> 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 . . .
>>
>> Since this will cause us to remain at
>> HAVE_NOTHING, authors must be very aware that duration and dimensions  
>> will
>> not be available.
>
> I don't see why anyone would possibly want this.  Browsers should
> *always* fetch duration and dimensions.  The cost should be on par
> with loading an extra image.

An opt-in for fetching nothing at all would be useful when used together  
with the poster attribute for something video galleries. This is the only  
form of "nobuffer" that makes any sense in my opinion, even though it can  
be done with scripts. Using it by mistake would visually break the page  
(unless poster is used), so I don't think the copy-paste problems aren't  
terrible.

The cost of getting the duration of a video file isn't *that* trivial, in  
particular with chained Ogg files where a binary search over the whole  
file must be done to find the duration of each part. For plain Ogg files,  
it requires two GETs, which is probably OK. However, delaying the load  
event while doing all of this seems unnecessary when a poster image is  
used, as the layout doesn't depend on the video size (in my opinion the  
poster size should be used until playback starts, but the spec lets the  
browser decide, unfortunately).

I had originally intended to implement poster attribute by stalling the  
resource fetch algorithm at the beginning, but this will cause "NaN" to be  
visible in scripted controls and perhaps break scripts which assume that  
HAVE_METADATA will be reached at onload. That's why the feature must be  
opt-in, if it should exist at all.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Sunday, 3 January 2010 23:40:42 UTC