Re: Public feedback on HTML5 video

On Mon, 28 Dec 2009 14:10:29 +0100, Scheppe, Kai-Dietrich  
<k.scheppe@telekom.de> wrote:

> Hi Philip,
>
>> Do you have a concrete suggestion on what the behavior should
>> be and how to control it? It seems to me that none of the
>> options are really good.
>
> 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)

autobuffer does this.

> - whether a poster frame is to be loaded or not (the poster attribute  
> does this)
>   However, there is also mention of doing so only when no video is  
> available...that is not enough.  A poster frame should simply be a  
> choice of the author.

I honestly don't understand what you are saying here. What is not enough?  
Does something need to be changed in the spec?

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

The poster image can only be an image file, where from the video it is  
taken (if at all) hardly needs to be represented in HTML.

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

Let the video be covered by what? The poster image and video are never  
displayed at the same time.

>> 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), while not
>> downloading anything and pretending that the duration is +Inf
>> and dimensions unknown is likely to cause headaches for
>> authors that actually use that data in their scripts before playing.
>
> If an author were to decide to offer 100s of videos on one page, then he  
> better have a very good reason to do so.
> One that his audience agrees with :-)
> Arguing in extremes is not useful as I can break any system that way.

This "extreme" is the only case which is interesting to discuss. For a  
single <video> the buffering behavior hardly matters at all since the  
options are (1) downloading nothing and (2) downloading a few 100 KB from  
the beginning and end of the video.

> Most likely an author will know exactly how many videos are being  
> offered per page, where "page" is also a flexible construct.
> For example, in a three column set up with, with 4-n rows there might be  
> several screens worth of content.
> It might be an author's choice to buffer only the top left video or the  
> top row or the grid of n videos that might fit on a "standard" screen  
> resolution.

Yes, autobuffer does this.

> On mobile devices this would yet again be rendered differently, based on  
> device capabilities, bandwith etc.
> ...but again calling for author's choice.
>
>
>> 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.
>
> Poster images are marketing tools...it's what makes the user want to  
> click on it.
> It also fills the spot...otherwise you might have a hole in your page  
> with, at best, a PLAY icon being displayed.
> As such it is highly useful.
> Using it to download some meta data about the video seems very  
> resonable, as it would allow display of such info and decision making by  
> the user.

Downloading and decoding an image is not necessarily faster than  
downloading and decoding the first frame of a video. I agree that it is  
useful because it can represent something other than the first frame of  
the video (which is often black). However, this really isn't related to  
the buffering behavior.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 28 December 2009 13:36:36 UTC