Re: Public feedback on HTML5 video

On Mon, Dec 28, 2009 at 7:09 AM, Scheppe, Kai-Dietrich
<k.scheppe@telekom.de> wrote:
> However, please keep in mind that I was primarily making a point of implicit vs. explicit instructions.
> If I tell the browser to do something, explicitly, then I expect precicely that to happen.

That is not desirable in all cases.  Sometimes the browser should have
leave to override the author.  For instance, if you try to create a
popup window in JavaScript, browsers might block that if they don't
think the user would like to see the pop-up.  Likewise, if you tell
the browser to download tons of content and it doesn't want to hog all
the user's bandwidth, the browser should always be able to ignore you.
 There's a balance to be struck here, and it's not all on the author's
side.

> Thus I find it preferable to enable the author to decide which video ought to be buffered and which not.

This is currently the case.  The author can specify autobuffer to ask
if a video be buffered, and not if they don't want it to be buffered.
Is there anything that needs to change here?

> It is the authors who know what's best for their audience, within their given context.

The author doesn't know if the user is on a mobile connection where
they're paying by the byte.  The browser might have a better idea
(e.g., if it's a mobile browser).

> In the end, however, it is up to the user to decide if they like the content or not.
> If authors make the wrong choices, users will vote with a click :-)

And if implementers make the wrong choices, users will vote by
downloading a different browser.  Sometimes users use a different
browser or enable a browser feature precisely because it overrules
author choices they don't like -- for instance, popup blocking.

Pages should operate for the best benefit of the *user*.  Sometimes
the author is in a better position to evaluate that, sometimes the
browser implementer.  It depends.  In the case of autobuffering, I
think what we have now is correct: the author specifies the behavior
(buffer or not), but the browser is allowed to override that with good
reason (like if it's on a mobile connection, explicit user preference,
etc.).

On Mon, Dec 28, 2009 at 7:32 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> Assuming a page with 100s of <video>s with poster images, downloading even
> just enough to get the duration might add up to a significant amount of data
> (and time)

Surely no more than a page with hundreds of images?  It should be fine
to get the duration/dimensions here.  This is a rare case, obviously,
and it's okay if it takes a little while for all the data to percolate
in.

> In either case, the poster image doesn't seem very useful if it doesn't
> allow authors to save bandwidth and/or display the page faster, none of
> which seem to be true in current implementations. I would like the presence
> of poster to allow browsers to not even try downloading any data (and the
> spec allows it), but am not sure this is what authors would want in all
> cases.

The poster image is meant for aesthetics, I think, not bandwidth
savings.  The first frame of the video is often a poor representation
of what the video will actually contain.  A title page or interesting
scene would be better, and the browser can't figure that out by
itself.

On Mon, Dec 28, 2009 at 8:10 AM, Scheppe, Kai-Dietrich
<k.scheppe@telekom.de> wrote:
> The author should be able to communicate to the browser
> - whether it should buffer or not (determining how much this would be is something best left to the browser manufacturer)
> - whether a poster frame is to be loaded or not (the poster attribute does this)

The author can do both of these.

> - perhaps even where on the timeline the poster frame is to be found, if it is not an explicit file

This should be possible eventually with media fragments.

> - the explicit dimensions of the video and let the video be covered partially if it is larger than that.

The width and height attributes should cover this.

> On mobile devices this would yet again be rendered differently, based on device capabilities, bandwith etc.
> ...but again calling for author's choice.

The author shouldn't have to write a separate page for mobile users
and make different decisions.  Mobile browsers should be allowed to
just ignore autobuffer if they think it's a good idea.


I'm not clear what changes you want to the spec.  Making autobuffer
mandatory?  Do you really think browsers shouldn't be allowed to
ignore it if they know they're on a connection with expensive
bandwidth?  They should normally obey it, everyone agrees to that.

Received on Monday, 28 December 2009 14:44:01 UTC