Re: [whatwg] Interpretation of video poster attribute
On Thu, 12 Jun 2008, Philip J�genstedt wrote: video poster=image_of_unknown_dimension src=video_of_unknown_but_same_dimension/video This is a probable and reasonable scenario, but currently it's impossible to use a poster image without knowing its dimensions. It's not impossible; first black would render 300x150, then the poster would render in that same 300x150 box, and then when the video comes in, the box would grow to fit the video and the video would render in that box. The poster works fine, it just doesn't size the video box to itself. How often will the poster be the right size? I suppose we could require the poster to be the same size as the video if the height/width attributes are absent. That the element may be resized twice is not a problem, at least not implementation-wise. That it's resized at all is a terrible problem; that it would resize twice would be a disaster, UI-wise. Since the poster image will only be displayed until the video starts playing, the options when width/height is not given are: 1. the poster image is displayed at size 300x150 for several seconds while the video is loading, after which the video element takes the size of the video 2. the poster image is displayed at its native size for several seconds while the video is loading, after which the video element takes the size of the video (which will often be the same size) Since a resize is possible in both cases (but less likely in case 2) both are equally problematic UI-wise, except that the image will actually be displayed with its correct dimensions in case 2. Both cases will start at 300x150 until the poster frame is downloaded. The question is whether we get one resize or two. This is just to provide sane defaults for authors who trust the browser to do the right things in absence of width/height. Safari already uses the intrinsic dimensions of the poster image and then resizes to the intrinsic dimensions of the video, which is exactly the behavior we want to implement. On Thu, 12 Jun 2008, Chris Double wrote: This is the behaviour I was planning to implement for poster too btw. As a user of the video element it seemed the most logical to me. Fine, fine, I'll spec that. :-) Note that this all falls apart if there are multiple videos of different dimensions, or if the video has a pixel ratio set. In the absence of a poster attribute does Safari load the first frame of the video and display that? I seem to recall it did when using a quicktime movie but not with a Theora movie using the XiphQT plugin. Is displaying the first frame of the video something that's useful? In the Firefox implementation I display the first frame, but I should be displaying nothing, right? When a video element is paused and the current playback position is the first frame of video, the element represents either the frame of video corresponding to the current playback position or the image given by the poster attribute, at the discretion of the user agent. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Interpretation of video poster attribute
On Thu, 2008-06-12 at 07:15 +, Ian Hickson wrote: So, to summarise, an img represents its src=, and a video represents its poster=. So use the same mechanism (stretching the image to fit the box dimensions) for both. Fair enough. This isn't currently defined (even without a poster, as far as I can tell), but my intention would be to not make the poster affect the intrinsic dimensions, and for the default, in the absence of video data, is 300x150. The problem with scaling to the poster's size is that it would make the veo resize twice e (300x150 - poster - video) instead of just once (300x150 blank, then poster - video). If poster is to video what src is to img, then surely the video element should take the size of the poster image if no width/height is given? This is certainly my preference, as width/height would otherwise effectively be mandatory when poster is used, which would in turn require the poster to be of the same size as the video unless one is to be scaled. That the element may be resized twice is not a problem, at least not implementation-wise. As some container formats allow changing the video frame size mid-stream (notably chained Ogg streams, so called sequential multiplexing) the UA could possibly resize the video element an unlimited number of times, so handling that is necessary anyway. On that note, perhaps an event to notify JavaScript UIs of such changes would be useful/necessary. Perhaps reusing resize event would be the best, other names could be videochange or sizechange. Should aspect ratio correction be done for poster images? What if different videos have different aspect ratios? It would be bad for the poster frame to be rendered at different ratios as the UA tries each video in turn. Good point, assuming 1:1 pixel ratio for poster images makes more sense, even if it means tools for automatically generating poster images will have to perform aspect ratio correction. HTTP 4xx and 5xx errors (and equivalents in other protocols) must (may?) cause the user agent to ignore the poster attribute. Well what else are they going to do? HTTP already requires this as far as I can tell. It appears that Safari shows a little X symbol instead, but perhaps specifying this behavior is not necessary. We will likely ignore the poster attribute entirely instead. I'm not sure a fake button (which wouldn't actually work anyway) is a natural interpretation of poster frame. :-) As long as it's mentioned somewhere there can be no misunderstanding. -- Philip Jägenstedt Opera Software
Re: [whatwg] Interpretation of video poster attribute
On Thu, 12 Jun 2008, Philip J�genstedt wrote: This isn't currently defined (even without a poster, as far as I can tell), but my intention would be to not make the poster affect the intrinsic dimensions, and for the default, in the absence of video data, is 300x150. This is defined now by the way. The problem with scaling to the poster's size is that it would make the veo resize twice e (300x150 - poster - video) instead of just once (300x150 blank, then poster - video). If poster is to video what src is to img, then surely the video element should take the size of the poster image if no width/height is given? This is certainly my preference, as width/height would otherwise effectively be mandatory when poster is used, which would in turn require the poster to be of the same size as the video unless one is to be scaled. Why? The posted would be displayed in the default 300x150 box. That the element may be resized twice is not a problem, at least not implementation-wise. That it's resized at all is a terrible problem; that it woul resize twice would be a disaster, UI-wise. As some container formats allow changing the video frame size mid-stream (notably chained Ogg streams, so called sequential multiplexing) the UA could possibly resize the video element an unlimited number of times, so handling that is necessary anyway. That's not the common case, though; a poster is. On that note, perhaps an event to notify JavaScript UIs of such changes would be useful/necessary. Perhaps reusing resize event would be the best, other names could be videochange or sizechange. I've noted this for a v3 feature. HTTP 4xx and 5xx errors (and equivalents in other protocols) must (may?) cause the user agent to ignore the poster attribute. Well what else are they going to do? HTTP already requires this as far as I can tell. It appears that Safari shows a little X symbol instead, but perhaps specifying this behavior is not necessary. We will likely ignore the poster attribute entirely instead. Showing a red X seems contrary to the spec (which says that the video element represents the poster, the video, or nothing), but really rendering things are out of scope of the spec. In any case, in a few years we'll probably look at what implementations do and specify what the implementations have converged on. I'm not sure a fake button (which wouldn't actually work anyway) is a natural interpretation of poster frame. :-) As long as it's mentioned somewhere there can be no misunderstanding. Ok, added a note. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Interpretation of video poster attribute
On Thu, 2008-06-12 at 09:56 +, Ian Hickson wrote: The problem with scaling to the poster's size is that it would make the veo resize twice e (300x150 - poster - video) instead of just once (300x150 blank, then poster - video). If poster is to video what src is to img, then surely the video element should take the size of the poster image if no width/height is given? This is certainly my preference, as width/height would otherwise effectively be mandatory when poster is used, which would in turn require the poster to be of the same size as the video unless one is to be scaled. Why? The posted would be displayed in the default 300x150 box. video poster=image_of_unknown_dimension src=video_of_unknown_but_same_dimension/video This is a probable and reasonable scenario, but currently it's impossible to use a poster image without knowing its dimensions. That the element may be resized twice is not a problem, at least not implementation-wise. That it's resized at all is a terrible problem; that it woul resize twice would be a disaster, UI-wise. Since the poster image will only be displayed until the video starts playing, the options when width/height is not given are: 1. the poster image is displayed at size 300x150 for several seconds while the video is loading, after which the video element takes the size of the video 2. the poster image is displayed at its native size for several seconds while the video is loading, after which the video element takes the size of the video (which will often be the same size) Since a resize is possible in both cases (but less likely in case 2) both are equally problematic UI-wise, except that the image will actually be displayed with its correct dimensions in case 2. This is just to provide sane defaults for authors who trust the browser to do the right things in absence of width/height. Safari already uses the intrinsic dimensions of the poster image and then resizes to the intrinsic dimensions of the video, which is exactly the behavior we want to implement. -- Philip Jägenstedt Opera Software
Re: [whatwg] Interpretation of video poster attribute
On Thu, 12 Jun 2008 13:22:40 +0200, Chris Double [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 10:36 PM, Philip Jägenstedt [EMAIL PROTECTED] wrote: This is just to provide sane defaults for authors who trust the browser to do the right things in absence of width/height. Safari already uses the intrinsic dimensions of the poster image and then resizes to the intrinsic dimensions of the video, which is exactly the behavior we want to implement. This is the behaviour I was planning to implement for poster too btw. As a user of the video element it seemed the most logical to me. I agree. In the absence of a poster attribute does Safari load the first frame of the video and display that? Yes. I seem to recall it did when using a quicktime movie but not with a Theora movie using the XiphQT plugin. Is displaying the first frame of the video something that's useful? Well, I think it is. :-) In the Firefox implementation I display the first frame, but I should be displaying nothing, right? Why? The spec says: When a video element is paused and the current playback position is the first frame of video, the element represents either the frame of video corresponding to the current playback position or the image given by the poster attribute, at the discretion of the user agent. -- Simon Pieters Opera Software
Re: [whatwg] Interpretation of video poster attribute
Hi again, Reading http://lists.w3.org/Archives/Public/public-html/2007Oct/0108.html it is clear that the intention of the poster attribute is to represent a still image from the video. This should probably be made explicit in the spec with something in the style of: The poster image typically represents a still frame of video. User agents must (may?) take this into account by applying the same rules as for rendering video (aspect ratio correction, scaling, centering). HTTP 4xx and 5xx errors (and equivalents in other protocols) must (may?) cause the user agent to ignore the poster attribute. This needs to be clear as there are two quite natural interpretations of what kind of image the user agent can show while no video data is available. The first is an unscaled, centered click to play button, while the second is a scaled, centered and aspect ratio corrected still frame from the video. Philip On Tue, 2008-06-03 at 10:00 -0500, Tab Atkins Jr. wrote: On Tue, Jun 3, 2008 at 7:36 AM, Philip Jägenstedt [EMAIL PROTECTED] wrote: Hi! I'm a bit puzzled about how to interpret the poster attribute on HTMLVideoElement: The poster attribute gives the address of an image file that the user agent can show while no video data is available. The attribute, if present, must contain a URI (or IRI). Is the intention that this image should be stretched to the size of the video element, or that it should be centered in the frame? If the width and height attributes are not given, should the video element initially be given the size of the poster image, or should the user agent wait until it has the dimensions of the video (thereby making the poster useless)? In short, what is the intended use of poster? -- Philip Jägenstedt Just for similar-implementation-ideas, flvplayer simply aligns the poster image to the upper-left of the object element, with no scaling at all. If width and height are not given, it simply doesn't display at all. Unless there's already some alternate intent, I suggest video scale to the poster's size if no explicit size is given. ~TJ
[whatwg] Interpretation of video poster attribute
Hi! I'm a bit puzzled about how to interpret the poster attribute on HTMLVideoElement: The poster attribute gives the address of an image file that the user agent can show while no video data is available. The attribute, if present, must contain a URI (or IRI). Is the intention that this image should be stretched to the size of the video element, or that it should be centered in the frame? If the width and height attributes are not given, should the video element initially be given the size of the poster image, or should the user agent wait until it has the dimensions of the video (thereby making the poster useless)? In short, what is the intended use of poster? -- Philip Jägenstedt
