[whatwg] Html 5 video element's poster attribute

[Monty Montgomery]

Ah, interesting, I just wasted most of last night trying to figure out
why I couldn't get poster to do anything sane or useful in Chrome or
Firefox (actually-- FF4 betas change behavior completely and the
poster.. sort of... behaves as expected).

>> Currently the poster disappears as soon as the first frame has been
>> downloaded, which typically takes a second. The player then shows this first
>> frame, but 99% of the time the first frame is black. So what you see is a
>> black box.
>
> Not quite: this is an implementation decision that Webkit-based browsers
> made. Neither Opera nor Firefox work that way (haven't checked IE yet).

Firefox 3.x practically never shows the poster.  As soon as it has a
frame, boom, poster is gone and I've got a big blank square.  This is
almost instant.  I'm in the process of scripting my own controls from
scratch so I can force-overlay the video element with an absolute
<div> to show the poster until the user hits play (I have to
reimplement controls, as overlaying a div hides the native controls;
they don't pop and they wouldn't get events if they did, or even if I
forwarded them as the native FF controls ignore synthesized events).

FF4 beta shows the poster until the first frame is played (yay).
Chrome is the polar opposite from FF3 and shows the poster anytime it
doesn't have a frame ready right now, meaning it shows up constantly
during seeking, layout changes and stutters.  [But Chrome's video
playback is darned near unusable anyway.  Why is the first minute of
every video just missing?]

>> The poster frame of a video is probably the most important not only for
>> the viewer but also for the content producer. It’s the one shot the content
>> producer gets at enticing the viewer to watch her video. Most video websites
>> therefore provide multiple ways in which the content producer can define a
>> poster frame for her video.

Now that I'm doing production to force myself to see this from the
viewpoint of the content producer, I couldn't agree more.

>> The solution would be the following:
>>
>> The poster frame should remain visible until the video is played.
>>
>> The poster should not show while the player is seeking (some browser
>> implementation do show the poster while seeking, resulting a flashes)

Yes, at a minimum Chrome does this.  With my producer hat on, it makes no sense.

>> The poster should show again after the video has ended.
>
> I think this would be confusing and would prefer it it just stays at
> displaying the last played frame. That gives users the visual queue that the
> playback has finished.

If the default action is to redisplay the poster, the other
possibilities are available via trivial scripting (remove it or even
replace it with a different poster after we start playing).  If the
poster does not redisplay and the content presenter wants it to, we're
back into scripting an entire control system from scratch, as
overlaying a div/image [to get the poster back] hides the native
controls and makes them inaccessable again.

FTR, if there is a way to overlay without muffling the controls under
an impenetrable [transparent/translucent/opaque] layer, do let me
know.

>> The visibility of the poster should be scriptable and/or controllable
>> using an attribute. Meaning that one should be able to turn on/off the
>> poster (without changing the poster attrbute’s value)
>
> Is this really necessary? What would be the use case? Either you want to
> poster - then you provide the attribute - or you don't want it - then you
> don't provide it. Also, per script you can remove the attribute and reset
> it, if you really need it. I don't see what an extra attribute would add?

Yes, I think this suggestion is one bridge too far and agree with Silvia.

I don't want exactly what I want with no scripting-- I want what I
want without a thousand lines of scripting to undo and subtly
reimplement a similar amount of C.

Monty
Xiph.Org