This is my comment. (steve at videojs)

I'd like to see this standardized too. In Opera, the poster is shown if and only if (poster_attr && !poster_failed && !(played_or_seeked && frame_decoded), where the states mean:

poster_attr: poster attribute is set
poster_failed: decoding the poster as an image failed
played_or_seeked: a play or seek has been requested
frame_decoded: a frame has been decoded (any frame)

(Obviously, it's also necessary to have decoded the poster image, but whenever the conditions are above are met we're "trying" to show the poster image, so it either eventually shows or the state switches to poster_failed.

All state is reset at the beginning of the resource selection algorithm.

In addition, whever the poster image is showing, the intrinsic size of the element is the size of the poster. In other words, the element is never resized to the size of the video while the poster image is still showing.

Needless to say, I'd be happy to standardize exactly what we already do :)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

This is a UI issue, no? Surely it should be left up to the browsers. What's the difference between the user quickly starting and pausing the video and the browser doing it automatically?

If the poster frame is displayed in some browsers but not others once the video starts loading, they'll be forced to hack around it by superimposing an <img> or burning a poster into the first frame of the video.  This defeats the entire point of the feature.  If something is visually part of the page contents, authors absolutely need to be able to control it reliably.  Authors are not going to accept "the poster frame I've carefully selected displays in some browsers until the user hits play, and in others it disappears almost immediately and is replaced by the first frame".

This isn't UI at all.  UI differences are where the same basic thing is displayed to the user, but in a UA-specific manner.  Here we're talking about two totally different things being displayed to the user: the poster and the first frame.  There's no reason not to demand interop here.

I don't get your last sentence at all.  We're talking about a case where no one has started playing the video at all.  What does starting and immediately stopping it have to do with anything?  Once the video has started playing, the poster shouldn't display anymore, as the spec says: "the poster frame should not be shown again after a frame of video has been shown."

(In reply to comment #3)

> This is a UI issue, no? Surely it should be left up to the browsers. What's the
> difference between the user quickly starting and pausing the video and the
> browser doing it automatically?

Why would a browser ever play and pause automatically? That would fire spurious events...

mass-move component to LC1

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Fair enough.

Checked in as WHATWG revision r6454.
Check-in comment: Be less flexible about what UAs are allowed to do with <video>.
http://html5.org/tools/web-apps-tracker?from=6453&to=6454