[whatwg] video tag: pixel aspect ratio

On Mon, 1 Dec 2008 j at oil21.org wrote:
>
> why should this be different for images and video?

Why should it be the same, other than consistency? I wouldn't make <img> 
stretch either if I was defining it today. Allowing stretching of images 
enabled a lot of problems, such as images at the wrong ratio, 
presentational use of images, etc.


> there are ways to center elements inside a "playback area".

Why makes things more complicated than necessary?


> how would i stretch a video if its always displayed in the aspect ratio 
> from the container, i.e. to have an animation where the video is a dot 
> first, than gets stretched to a thin 5 x 480 element and than unfolds to 
> its full dimensions 640x480.

Animations of that nature should be done either using SVG or CSS 
transforms, not at the HTML level.


On Mon, 1 Dec 2008, Philip J?genstedt wrote:
> > >
> > > Now that the pixelratio override is gone, shouldn't the influence of 
> > > pixel aspect ratio on the layout be removed also?
> > 
> > It is, isn't it? What did I leave in?
> 
> "Video content should be rendered inside the element's playback area 
> such that the video content is shown centered in the playback area at 
> the largest possible size that fits completely within it, with the video 
> content's aspect ratio being preserved. Thus, if the aspect ratio of the 
> playback area does not match the aspect ratio of the video, the video 
> will be shown letterboxed or pillarboxed. Areas of the element's 
> playback area that do not contain the video represent nothing."

That's what it said before we added pixelratio="".


> > We definitely don't want to stretch the video. One of the important 
> > use cases if having a video playback area and then playing videos with 
> > different aspect ratios in that playback area. It should all just 
> > work.
> 
> I'm having a hard time seeing how this is a use case for video and not 
> for img.

I don't understand how it's a use case for <img> either.


> If one wants the intrinsic width/height to be used, then simply don't 
> set width/height. Otherwise, just setting just one of width/height or 
> using CSS max-width/max-height should do the trick.

The idea is that generally you don't want the intrinsic size to be used, 
you want a consistent size to be used, and you would set it from CSS.


> This is strange:
> 
> <video src="circle.mpg" width="400" height="400"> <!-- circle -->
> <video src="circle.mpg" width="400" height="300"> <!-- pillarbox -->
> 
> <img src="circle.jpg" width="400" height="400"> <!-- circle -->
> <img src="circle.jpg" width="400" height="300"> <!-- oval -->
> 
> I think it would be much more consistent if these elements behaved in 
> the same way.

I don't think consistency here is an issue. Or if you like, consider it 
as being consistent with <iframe>:

   <iframe src="circle.html" width="400" height="400"> <!-- circle -->
   <iframe src="circle.html" width="400" height="300"> <!-- pillarbox -->


> As it stands, after the pixelratio was removed, there is no way to 
> display a circle as an oval or vice versa, which means it is both 
> impossible to fix an incorrect aspect ratio or to stretch the video for 
> some other purpose.

Right; we established that the use cases for stretching the video were not 
convincing, that's why I removed pixelratio="".


On Mon, 1 Dec 2008, Lachlan Hunt wrote:
> 
> This is effectively how YouTube behaves now with their recent change to 
> a widescreen player.  It would look terrible if 4:3 videos were 
> stretched to fill the 16:9 viewport, instead of just using black bars on 
> the side.  Even before when they were still using a 4:3 player, 
> widescreen videos were rendered as letterbox.

True.


On Mon, 1 Dec 2008, Pierre-Olivier Latour wrote:
> 
> I can only think of the case when you need to post-fix a video which 
> wasn't encoded with the proper pixel aspect ratio. And we already 
> covered the likelihood of encountering this case extensively. So I guess 
> what's left is purely a convention decision:
>
> - should <video> behaves like <img> by default and have a special 
> attribute to scale proportionally,
>
> - or should <video> scale proportionally by default, and maybe have some 
> way of defining a stretching behavior?
> 
> Eric & I would recommend the later because based on past experience, 
> users often specify the wrong width & height for the element, and if we 
> stretch by default, then we would often fall off the fast path of the 
> media engine (scaling anamorphically can be very expensive). At the end 
> of the day, being consistent with <img> wouldn't be worth the potential 
> other issues.
> 
> Regarding the stretch attribute, we should have this functionally 
> available to users but preferably at the CSS level.

I agree that something like stretch or pixelratio should probably be added 
in a future version, but since we just removed pixelratio="" I don't think 
it is something we want to add now.


On Mon, 1 Dec 2008, Martin Atkins wrote:
> 
> It would also be useful if this mechanism were available for images. A 
> bunch of times I've written code to proportionally scale images to 
> create smaller versions, and I'd much rather just set this with CSS.
> 
> This would also go some way to increase the consistency, since the 
> difference between IMG and VIDEO would be merely a difference in the 
> default stylesheet rules for each element.

True.


On Mon, 1 Dec 2008, Philip J?genstedt wrote:
> 
> The strange part isn't that the video is pillarboxed, but that it's 
> impossible to not do it and that it's inconsistent with <img>.

There are inconsistencies all over the place already. This doesn't add a 
new one, since <img>, <iframe>, and <video> already act differently in so 
many ways.


> The use case for stretching moving images (<video>) is exactly the same 
> as for stretching animations (<img src=animation.gif>) or static images 
> (<img src=static.jpg>). While I think that fixing incorrect aspect ratio 
> is the most probable use, consistency and generality is the real issue 
> here. With an image of size 800x600 it's possible to display at any 
> size, even those which don't match the aspect 4:3. With moving images 
> (video) we can't influence it at all.

If consistency is the only use case, then I don't think that's convincing.


> The previous solution was the pixelratio attribute, but I have 2 other
> possible solutions:
> 
> <video src="4x3.mpg" width="1920" height="1080" keepaspect>
> 
> The video would be pillarboxed.
> 
> <video src="4x3.mpg" width="1920" height="1080">
> 
> The video would be stretched and have incorrect aspect, just like
> 
> <img src="4x3.jpg" width="1920" height="1080">
> 
> This way it's easy to stretch or to keep aspect, whichever you want.

I fear that if we do this, authors will screw up the ratio a lot. The 
whole point of <video> is to not provide too many ways that authors can 
screw things up.


> Given the number of people who watch 4:3 video stretched to a 16:9 
> display without even noticing/caring that the aspect ratio is wrong, I 
> don't think we can trust that the aspect ratio of all videos is always 
> going to be correctly encoded and simple say that this should be fixed 
> by reencoding the video -- that's not even an option if the source file 
> is not available and reencoding is good for quality.

Making it easy for authors to screw it up more isn't a way to solve this. :-)

pixelratio="" was an ok solution because it was unlikely to be used much, 
but height/width will be used all over the place if we allow it.


On Mon, 1 Dec 2008, Philip J?genstedt wrote:
> 
> Another way could be using CSS so that the same thing could be done with 
> <img>. It is in fact rather difficult to scale something to fit inside a 
> box using only CSS right now, so a general solution for it would be 
> nice. Possibly <video style="scaling:keep-aspect"> or something like 
> that? This way one could let the default value differ between <img> and 
> <video> if the aspect-preserving (letterboxing/pillarboxing) is judged 
> to be much more common than the "aspect-fixing" mode.

I agree that CSS (maybe taking something from SVG and making it more 
general) would be a good way to address this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 1 December 2008 14:06:06 UTC