Re: [whatwg] video tag: pixel aspect ratio
On Sun, Nov 30, 2008 at 11:05 PM, Chris Double [EMAIL PROTECTED] wrote: On Mon, Dec 1, 2008 at 7:11 PM, Peter Kasting [EMAIL PROTECTED] wrote: I don't think it is the end of the world if this attribute goes in, but I see very little benefit to it, and I am always for removing items with marginal utility. I'm inclined to agree. I think it's odd that an attribute is being added to fix video's encoded incorrectly. Why can't the author of the video fix the actual video? One of the arguments for captions being embedded in video's rather than having some way of defining captions by the page author was that it's important not to use HTML to fix broken videos, and allow captions to travel with the file. The same argument could be made for pixel ratio. Fixing it in the HTML means everyone linking to the file using video will need to remember to add pixelratio to their HTML. Better to fix the file. Can someone provide examples of videos on the web that are currently broken, and a pixel ratio that would fix it? As an HTML author that wants to embed a video on my website I don't think I'd have any idea how to come up with a pixel ratio to fix it. Another thing, if I as a website developer find a video that was encoded with the wrong pixel ratio, wouldn't the simplest, and most intuitive, way to fix it be to simply set a width and height on video until it looked approximately correct? Yes, it's a hack, and should not discouraged, but so is pixelratio. (haven't followed this discussion in detail so appologies if width/height has been disqualified already) / Jonas
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 1 Dec 2008, Jonas Sicking wrote: Another thing, if I as a website developer find a video that was encoded with the wrong pixel ratio, wouldn't the simplest, and most intuitive, way to fix it be to simply set a width and height on video until it looked approximately correct? Yes, it's a hack, and should not discouraged, but so is pixelratio. (haven't followed this discussion in detail so appologies if width/height has been disqualified already) width/height on video doesn't stretch, so that you can play videos of varying aspect ratios in the same surface without rendering issues. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
On Mon, Dec 1, 2008 at 12:37 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 1 Dec 2008, Jonas Sicking wrote: Another thing, if I as a website developer find a video that was encoded with the wrong pixel ratio, wouldn't the simplest, and most intuitive, way to fix it be to simply set a width and height on video until it looked approximately correct? Yes, it's a hack, and should not discouraged, but so is pixelratio. (haven't followed this discussion in detail so appologies if width/height has been disqualified already) width/height on video doesn't stretch, so that you can play videos of varying aspect ratios in the same surface without rendering issues. Ah, makes sense. Wasn't there once upon a time a CSS draft that let you specify how replaced elements should stretch in situations like this? So you could choose if it should zoom-to-fit (like it sounds like video does) or stretch-to-fit (like img does), zoom-to-fill as well as a few other things. I can't seem to find it though... I guess my point is, can we let CSS deal with this? If it indeed needs to be dealt with. / Jonas
Re: [whatwg] video tag: pixel aspect ratio
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? I would prefer if the default were to stretch to fit if both width/height are given, just like for img. Letterboxing/pillarboxing should be the special case, is the idea that we should have the equivalent of SVG:s preserveAspectRatio either via CSS or HTML? 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: 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. why should this be different for images and video? there are ways to center elements inside a playback area. 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. +1 for stretch to fit if both width/height. j
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: On Mon, 1 Dec 2008, Philip Jgenstedt 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. I would prefer if the default were to stretch to fit if both width/height are given, just like for img. Letterboxing/pillarboxing should be the special case, is the idea that we should have the equivalent of SVG:s preserveAspectRatio either via CSS or HTML? 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. 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. 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. 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. So, what is the difference between images and moving images? -- Philip Jägenstedt Opera Software
Re: [whatwg] video tag: pixel aspect ratio
Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: 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. 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. This is strange: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- 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. 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. What is the use case for wanting a video to be stretched? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 18:19 +0100, Lachlan Hunt wrote: Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: 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. 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. This is strange: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- 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. 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. 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. What is the use case for wanting a video to be stretched? 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. 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. 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. But to reiterate, this is mainly about generality and consistency. Are there any other suggestions? Could this perhaps be done with 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. It would be rather sad to see img and video be so inconsistent when -- Philip Jägenstedt Opera Software
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 1 Dec 2008 [EMAIL PROTECTED] 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
Re: [whatwg] video tag: pixel aspect ratio
Philip Jägenstedt wrote: 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). Consistency is not a use case. For images, we're constrained by backwards compatibility requirements to stretch them, rather than keep aspect ratios, regardless of what use cases there may or may not be for doing so. For video, we are not constrained by such backwards compatibility and we have the opportunity to specify the most rational alternative as the default. While I think that fixing incorrect aspect ratio is the most probable use, consistency and generality is the real issue here. Given that the pixelratio attribute was dropped in part due to a lack of compelling use cases, I don't think the same use case will be compelling for this either. If there are real use cases for stretching video, then they should be judged on their own merits, rather than just falling back to the consistency argument. 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. 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. Retaining the aspect ratio needs to be the default because based on experience with video on the web today, e.g. on YouTube, and also based on the behaviour of common media players, like VLC, QuickTime, Windows Media, etc. When a user resizes their video player, the video generally maintains the aspect ratio and gets black bars; (or in QuickTime's case, the window size is constrained by the video's aspect ratio). There are menu options in VLC, and possibly others, to set the aspect ratio of a video to a selection of common aspect ratios, but there is no arbitrary scaling (at least, not that I'm aware of). video src=4x3.mpg width=1920 height=1080 The video would be stretched and have incorrect aspect And if a user chooses to put the video in full screen, then what? Should it maintian that incorrect aspect ratio? Should it stretch to fill the whole screen, regardless of what type of monitor the user is using, or should it use the video's default aspect ratio? 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, While I'm aware that there are such people, largely because they don't know how to configure their TV's properly or because their TV's are broken by design, there are many others who do notice the difference (including myself). From my experience, stretching a 4:3 picture to fill a 16:9 screen is enough to make people on the screen look weird and out of proportion. It's less noticeable with cartoons, but in general, it's very noticeable and annoying. We should inflict such annoyances upon end users if it avoidable; at least not by default. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] video tag: pixel aspect ratio
BTW, using CSS transforms (not a standard yet, but implemented in Webkit and Gecko now), you can stretch video (or anything else) any way you want. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] video tag: pixel aspect ratio
On Tue, Dec 2, 2008 at 4:19 AM, Lachlan Hunt [EMAIL PROTECTED] wrote: Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- 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. Not all video players behave like the YouTube one though. Many stretch with the width/height attributes. I would support an explicit keepaspectratio attribute, which turns the width/height from a video width/height to a viewport. In fact, such an attribute would be awesome for images, too. It could be a CSS attribute or an explicit video element attribute - I am not fussed. Regards, Silvia.
Re: [whatwg] video tag: pixel aspect ratio
Am Dienstag, den 02.12.2008, 11:02 +1100 schrieb Silvia Pfeiffer: I would support an explicit keepaspectratio attribute, which turns the width/height from a video width/height to a viewport. In fact, such an attribute would be awesome for images, too. It could be a CSS attribute or an explicit video element attribute - I am not fussed. Better make it CSS – this is as presentational as it can get. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-12-01 at 23:07 +0100, Lachlan Hunt wrote: 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, While I'm aware that there are such people, largely because they don't know how to configure their TV's properly or because their TV's are broken by design, there are many others who do notice the difference (including myself). From my experience, stretching a 4:3 picture to fill a 16:9 screen is enough to make people on the screen look weird and out of proportion. It's less noticeable with cartoons, but in general, it's very noticeable and annoying. We should inflict such annoyances upon end users if it avoidable; at least not by default. The point wasn't that it is OK for UA:s to distort video because there are people who don't notice, but that some people do/will encode video with the wrong aspect ratio without noticing/caring. The general consensus seems to be that this isn't worth the effort fixing. But in any event, if a CSS solution is in fact possible that would be much better than any video-specific solution. I don't think CSS transforms can do it though, unless someone can give an example? -- Philip Jägenstedt Opera Software
Re: [whatwg] video tag: pixel aspect ratio
On Tue, Dec 2, 2008 at 11:02 AM, Silvia Pfeiffer [EMAIL PROTECTED] wrote: On Tue, Dec 2, 2008 at 4:19 AM, Lachlan Hunt [EMAIL PROTECTED] wrote: Philip Jägenstedt wrote: On Mon, 2008-12-01 at 12:39 +, Ian Hickson wrote: video src=circle.mpg width=400 height=400 !-- circle -- video src=circle.mpg width=400 height=300 !-- pillarbox -- 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. Not all video players behave like the YouTube one though. Many stretch with the width/height attributes. I checked this out a little more, since I remembered using the JW player for some flv videos and they were stretched to the size of the player no matter what their original encoded size. According to this thread http://www.jeroenwijering.com/?thread=13766 it depends on whether the video metadata contains the original width/height of the video. If it doesn't have that, the JW player stretches to whatever is given. Jeroen might have changed that by now, since it seems that many players now decode a few frames of video to determine the original width/height of the video if this information is not provided in the video metadata. There are tools to include such metadata into the video headers for the different video formats that exist and I am sure someone like YouTube will make sure that metadata is available. However, I would not expect the common user to be clever enough to make sure their videos provide this data. This raises a few questions: * Do we want to prescribe the use of the width/height metadata for determining the video size inside the viewport? * How often is the widht/height metadata in videos encoded with wrong values? * Do we want to force all video players to decode a few frames and get the correct width/height values to then adapt to the viewport? * Do we have use cases for overriding correct aspect ratio displays by users? (and should that then go into a CSS control?) I would much prefer the default video display to get it right inside a viewport, than to risk relying on users to get the aspect ratio right. Also, the viewport approach makes it easier to have a consistently sized video player rather than adapting the video player to the video's actual size and thus potentially constantly switching between 4:3 and 16:9. So (contrary to what I wrote just before), I think the attribute should not be a keepaspectratio attribute but rather something like fillviewport and it should probably be a CSS attribute. Cheers, Silvia.
Re: [whatwg] video tag: pixel aspect ratio
On Tue, 2 Dec 2008, Silvia Pfeiffer wrote: Not all video players behave like the YouTube one though. Many stretch with the width/height attributes. Yeah, it's really annoying. :-) I would support an explicit keepaspectratio attribute, which turns the width/height from a video width/height to a viewport. In fact, such an attribute would be awesome for images, too. It could be a CSS attribute or an explicit video element attribute - I am not fussed. I think that this belongs in CSS, for the reason Nils gave: On Tue, 2 Dec 2008, Nils Dagsson Moskopp wrote: Better make it CSS – this is as presentational as it can get. On Tue, 2 Dec 2008, Silvia Pfeiffer wrote: This raises a few questions: * Do we want to prescribe the use of the width/height metadata for determining the video size inside the viewport? We already do. * How often is the widht/height metadata in videos encoded with wrong values? Relatively often, IMHO, that's why I wanted pixelratio=. But we've established that this is not something we're addressing in v1. * Do we want to force all video players to decode a few frames and get the correct width/height values to then adapt to the viewport? We already force them to decode the end of the stream to get the right duration, having them decode one frame so that they can render that frame seems reasonable enough. * Do we have use cases for overriding correct aspect ratio displays by users? (and should that then go into a CSS control?) There are always use cases for presentational effects, and those indeed belong in CSS. I would much prefer the default video display to get it right inside a viewport, than to risk relying on users to get the aspect ratio right. Indeed. Also, the viewport approach makes it easier to have a consistently sized video player rather than adapting the video player to the video's actual size and thus potentially constantly switching between 4:3 and 16:9. Right. So (contrary to what I wrote just before), I think the attribute should not be a keepaspectratio attribute but rather something like fillviewport and it should probably be a CSS attribute. Agreed. On Tue, 2 Dec 2008, Philip J�genstedt wrote: The point wasn't that it is OK for UA:s to distort video because there are people who don't notice, but that some people do/will encode video with the wrong aspect ratio without noticing/caring. The general consensus seems to be that this isn't worth the effort fixing. Right, that's why we dropped pixelratio=. :-) But in any event, if a CSS solution is in fact possible that would be much better than any video-specific solution. I don't think CSS transforms can do it though, unless someone can give an example? Well, CSS transforms don't officially exist yet, but you could use a scale() or scaleX() transform: http://webkit.org/specs/CSSVisualEffects/CSSTransforms.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 17 Nov 2008, Pierre-Olivier Latour wrote: And the suggested hack is not even really usable: if you have a video coming from a NTSC DV source as 720x480 improperly transcoded to say MP4 720x480 square pixels, using the theoretical 10:11 pixel aspect ratio will _not_ make it look right: it needs to be clipped to 704x480 first. Are you sure? If you don't clip it, you still get the right shape pixels, don't you? You don't get the right final video size, sure, because you didn't crop, but so what? We're just trying to do a last-ditch aspect ratio fix here, not get perfect video. Well, the pixels will look right if you pass 10:11, but not the overall video, or the video will look right but not the pixels if you pass an aspect ratio to end up with 640x480 (the very nice 0.889)... Anyone who's using this attribute has long given up on getting perfect output; they just want to have circles look like circles. Pixel aspect ratio has a precise meaning in the video world, and using it outside of clean aperture does not make a lot of sense... As far as I can tell, using it outside clean aperture works fine so long as you don't also expect the final output to be the right video size. You're effectively saying that it works *fine* as long as you we don't expect to work *right*. I have to admit, this is a concept that escapes me ;) We're dealing with videos that are mis-encoded here, by definition (that's what the attribute is for). The biggest problem with misencoded videos is the ratio. The goal here is just to provide a way to hack the ratio to be right so that at least the biggest mistake is fixed. If we start going in this direction, then img should have a dpi attribute so you can hack around images uploaded at dpi 72 ;) We effectively do, it's the height (or width) attribute. Exactly my point: now replace, img by video, dpi by aspectRatio and add a new boolean attribute to the video tag, so you can do fillToFit instead of scaleToFit and you have a real solution that allows you to resize the video the way you want and avoids half-baked concepts like it's pixel aspect ratio, but actually not really, and you shouldn't be using it anyway. I don't understand why that would be better. If we did this, then there'd be no way to have a consistent playback area across multiple pages and fix the ratio of busted clips. You'd be forced to change the layout, which is hardly a quick fix. I might be missing something here, but: 1) I don't remember any major media system I've dealt with so far having an explicit pixel aspect ratio override API, 2) on the web, neither QT plug-in nor Flash have it, That might explain the large number of videos on the Web that are rendered at the wrong ratio without anyone doing anything about it. :-) 3) in the case of this spec, the way it's defined makes it behave incorrectly It doesn't support the clean aperture concept, and doesn't crop anything, certainly, but does it lead to the wrong ratio? 4) it's not straightforward to use (see very first reply above) I'm open to better ideas. 5) there's no _actual_ data that proves it's necessary (shouldn't the software or video web site fix the videos upfront?) Anecdotally, I see this quite a lot (several times a week). Based on this, it seems to me this attribute should not be in the spec by default, and we should switch the burden of the proof to people who want it (rather than it being on people who don't want it as it seems to be the case today), and finally wait to see 1) if there's a real need for a solution here and 2) if the best solution is indeed a pixel aspect ratio override. I'm certainly open to other solutions. What do you suggest? On Mon, 17 Nov 2008, Peter Kasting wrote: I agree. The more this attribute is discussed, the more this is a hack that no one should actually use starts to sound like we shouldn't put this in the spec to begin with. The potential for problems seems greater than the upside from authors correctly using this to do emergency-overrides of particular videos whose sources they don't control. I don't understand why this attribute would cause problems. Can you elaborate? On Mon, 17 Nov 2008, Philip J�genstedt wrote: I should point out that the pixelratio attribute isn't only for authors, it's also useful when the media framework used doesn't recognize the (pixel) aspect ratio even when it's correctly set. From reading the mplayer man page I see that AVI files can have aspect ratio set in the OpenDML vprp header, but I doubt e.g. DirectShow supports this (I could be wrong though). I don't feel very strongly about the attribute either way, but given that video is scaled to fit inside its element box with aspect preserved and not simply stretched then an incorrectly parsed/guessed aspect ratio would make a big difference.
Re: [whatwg] video tag: pixel aspect ratio
On Sun, Nov 30, 2008 at 9:11 PM, Ian Hickson [EMAIL PROTECTED] wrote: I might be missing something here, but: 1) I don't remember any major media system I've dealt with so far having an explicit pixel aspect ratio override API, 2) on the web, neither QT plug-in nor Flash have it, That might explain the large number of videos on the Web that are rendered at the wrong ratio without anyone doing anything about it. :-) Or, perhaps, authors don't care or the people who embed videos for playback without access to the original source files are unlikely to know much about getting aspect ratios correct, especially when it involves using confusing attributes that people are not supposed to use might explain it. I'm not sure what data could be used to determine which hypothesis is accurate. 5) there's no _actual_ data that proves it's necessary (shouldn't the software or video web site fix the videos upfront?) Anecdotally, I see this quite a lot (several times a week). Anecdotally, I never see this, and I watch a lot of video. YouTube's recent widescreen move has made me see a lot of boxed video, but that's not the same. The plural of anecdote is not data. To repeat the question, what sorts of _data_ motivate this? Based on this, it seems to me this attribute should not be in the spec by default, and we should switch the burden of the proof to people who want it (rather than it being on people who don't want it as it seems to be the case today), and finally wait to see 1) if there's a real need for a solution here and 2) if the best solution is indeed a pixel aspect ratio override. I'm certainly open to other solutions. What do you suggest? From reading the above paragraph, do nothing, for now. I don't see a problem in need of an HTML 5 spec solution. On Mon, 17 Nov 2008, Peter Kasting wrote: The potential for problems seems greater than the upside from authors correctly using this to do emergency-overrides of particular videos whose sources they don't control. I don't understand why this attribute would cause problems. Can you elaborate? * Authors specify the wrong ratio, causing videos to look worse * Authors, blindly copy-and-pasting, believe this attribute is required and specify it everywhere, increasing the likelihood of both of these bullet points If you think the likelihood of the first bullet is low, consider the confusion evident on this thread, and then extend that to authors who have even less of a clue. The attribute is confusing because your intended use -- as a hack that people shouldn't use -- is confusing. Videos encoded at the wrong aspect ratio are a real problem, but they are one of an extremely large number of real problems, most of which we (rightly) are not trying to solve. I think you have given a few reasons why we _aren't_ trying to solve others. I don't understand why we're trying to solve this one. I don't think it is the end of the world if this attribute goes in, but I see very little benefit to it, and I am always for removing items with marginal utility. PK
Re: [whatwg] video tag: pixel aspect ratio
On Mon, Dec 1, 2008 at 7:11 PM, Peter Kasting [EMAIL PROTECTED] wrote: I don't think it is the end of the world if this attribute goes in, but I see very little benefit to it, and I am always for removing items with marginal utility. I'm inclined to agree. I think it's odd that an attribute is being added to fix video's encoded incorrectly. Why can't the author of the video fix the actual video? One of the arguments for captions being embedded in video's rather than having some way of defining captions by the page author was that it's important not to use HTML to fix broken videos, and allow captions to travel with the file. The same argument could be made for pixel ratio. Fixing it in the HTML means everyone linking to the file using video will need to remember to add pixelratio to their HTML. Better to fix the file. Can someone provide examples of videos on the web that are currently broken, and a pixel ratio that would fix it? As an HTML author that wants to embed a video on my website I don't think I'd have any idea how to come up with a pixel ratio to fix it. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] video tag: pixel aspect ratio
On Mon, 2008-11-17 at 22:28 -0800, Sander van Zoest wrote: Depending on how you want to accomplish you can do that with an enum that defines how to handle the case: 1) do nothing. 2) disproportionately adjust 3) stretch follow by letter-,pillar-,windowbox appropriately. 4) complete fill the screen and ignore overscan (ala pan scan or zoom) The spec says 3, but if stretch behaviour is wanted I guess one could consider doing something like SVG:s preserveAspectRatio attribute[1] Oh, and if the video also needs cropping to get the correct aperture, couldn't this be done with CSS perhaps? Wow. How would you know how much to crop for each video clip? Wouldn't specifying the enum above do the trick? I don't know, is aperture encoded in the media file itself or is it implicit in certain types of video formats that aperture cropping (or whatever the technical term is) should be applied? If you should always crop e.g. 8 px on left and right then a CSS container with some overflow tricks would certainly work. If on the other hand it's given in the media file and it's likely to be incorrectly set then perhaps we do need an override for it (although it's likely that such cropping is performed by the video decoder and not a subsequent crop filter so it might not be so trivial to fix in all media frameworks). [1] http://www.w3.org/TR/SVG/coords.html#PreserveAspectRatioAttribute -- Philip Jägenstedt Opera Software
Re: [whatwg] video tag: pixel aspect ratio
On Mon, Nov 17, 2008 at 11:33 PM, Robert O'Callahan [EMAIL PROTECTED]wrote: On Tue, Nov 18, 2008 at 7:28 PM, Sander van Zoest [EMAIL PROTECTED]wrote: By the way, the pixel-aspect-ratio on video caps in the GStreamer framework has precisely the same meaning as this attribute, overriding it on a video sink also has an effect similar to what is suggested in the HTML5 spec. In other words, it's not so outlanding from a media framework's point of view. In the capture world it makes a lot of sense. You are converting analog content into digital. It is my understanding that HTML5 is presentation technology, not a video capture, transcoding or editing framework. Video capture is getting popular on the Web, so it would not be surprising to see HTML5 extend in that direction in the future. Sure, let's cross that bridge when we get there. I certainly can see usb-type cams and mics, but that is quite different then a full on video capture framework. -- Sander
Re: [whatwg] video tag: pixel aspect ratio
And the suggested hack is not even really usable: if you have a video coming from a NTSC DV source as 720x480 improperly transcoded to say MP4 720x480 square pixels, using the theoretical 10:11 pixel aspect ratio will _not_ make it look right: it needs to be clipped to 704x480 first. Are you sure? If you don't clip it, you still get the right shape pixels, don't you? You don't get the right final video size, sure, because you didn't crop, but so what? We're just trying to do a last-ditch aspect ratio fix here, not get perfect video. Well, the pixels will look right if you pass 10:11, but not the overall video, or the video will look right but not the pixels if you pass an aspect ratio to end up with 640x480 (the very nice 0.889)... Pixel aspect ratio has a precise meaning in the video world, and using it outside of clean aperture does not make a lot of sense... As far as I can tell, using it outside clean aperture works fine so long as you don't also expect the final output to be the right video size. You're effectively saying that it works *fine* as long as you we don't expect to work *right*. I have to admit, this is a concept that escapes me ;) If we start going in this direction, then img should have a dpi attribute so you can hack around images uploaded at dpi 72 ;) We effectively do, it's the height (or width) attribute. Exactly my point: now replace, img by video, dpi by aspectRatio and add a new boolean attribute to the video tag, so you can do fillToFit instead of scaleToFit and you have a real solution that allows you to resize the video the way you want and avoids half-baked concepts like it's pixel aspect ratio, but actually not really, and you shouldn't be using it anyway. Personally I don't really see the problem with pixelratio. I might be missing something here, but: 1) I don't remember any major media system I've dealt with so far having an explicit pixel aspect ratio override API, 2) on the web, neither QT plug-in nor Flash have it, 3) in the case of this spec, the way it's defined makes it behave incorrectly 4) it's not straightforward to use (see very first reply above) 5) there's no _actual_ data that proves it's necessary (shouldn't the software or video web site fix the videos upfront?) Based on this, it seems to me this attribute should not be in the spec by default, and we should switch the burden of the proof to people who want it (rather than it being on people who don't want it as it seems to be the case today), and finally wait to see 1) if there's a real need for a solution here and 2) if the best solution is indeed a pixel aspect ratio override. Pierre-Olivier Latour - [EMAIL PROTECTED] Rich Media Team - Apple, Inc.
Re: [whatwg] video tag: pixel aspect ratio
On Mon, Nov 17, 2008 at 1:58 PM, Pierre-Olivier Latour [EMAIL PROTECTED]wrote: 1) I don't remember any major media system I've dealt with so far having an explicit pixel aspect ratio override API, 2) on the web, neither QT plug-in nor Flash have it, 3) in the case of this spec, the way it's defined makes it behave incorrectly 4) it's not straightforward to use (see very first reply above) 5) there's no _actual_ data that proves it's necessary (shouldn't the software or video web site fix the videos upfront?) Based on this, it seems to me this attribute should not be in the spec by default, and we should switch the burden of the proof to people who want it (rather than it being on people who don't want it as it seems to be the case today), and finally wait to see 1) if there's a real need for a solution here and 2) if the best solution is indeed a pixel aspect ratio override. I agree. The more this attribute is discussed, the more this is a hack that no one should actually use starts to sound like we shouldn't put this in the spec to begin with. The potential for problems seems greater than the upside from authors correctly using this to do emergency-overrides of particular videos whose sources they don't control. PK
Re: [whatwg] video tag: pixel aspect ratio
I should point out that the pixelratio attribute isn't only for authors, it's also useful when the media framework used doesn't recognize the (pixel) aspect ratio even when it's correctly set. From reading the mplayer man page I see that AVI files can have aspect ratio set in the OpenDML vprp header, but I doubt e.g. DirectShow supports this (I could be wrong though). I don't feel very strongly about the attribute either way, but given that video is scaled to fit inside its element box with aspect preserved and not simply stretched then an incorrectly parsed/guessed aspect ratio would make a big difference. This seems very similar to the width/height attributes of an image and that usually isn't considered an ugly hack. If the pixelratio attribute is removed then I would suggest also removing the involvement of aspect ratio over the size of the element. By the way, the pixel-aspect-ratio on video caps in the GStreamer framework has precisely the same meaning as this attribute, overriding it on a video sink also has an effect similar to what is suggested in the HTML5 spec. In other words, it's not so outlanding from a media framework's point of view. Oh, and if the video also needs cropping to get the correct aperture, couldn't this be done with CSS perhaps? Philip On Mon, 2008-11-17 at 14:02 -0800, Peter Kasting wrote: On Mon, Nov 17, 2008 at 1:58 PM, Pierre-Olivier Latour [EMAIL PROTECTED] wrote: 1) I don't remember any major media system I've dealt with so far having an explicit pixel aspect ratio override API, 2) on the web, neither QT plug-in nor Flash have it, 3) in the case of this spec, the way it's defined makes it behave incorrectly 4) it's not straightforward to use (see very first reply above) 5) there's no _actual_ data that proves it's necessary (shouldn't the software or video web site fix the videos upfront?) Based on this, it seems to me this attribute should not be in the spec by default, and we should switch the burden of the proof to people who want it (rather than it being on people who don't want it as it seems to be the case today), and finally wait to see 1) if there's a real need for a solution here and 2) if the best solution is indeed a pixel aspect ratio override. I agree. The more this attribute is discussed, the more this is a hack that no one should actually use starts to sound like we shouldn't put this in the spec to begin with. The potential for problems seems greater than the upside from authors correctly using this to do emergency-overrides of particular videos whose sources they don't control. PK -- Philip Jägenstedt Opera Software
Re: [whatwg] video tag: pixel aspect ratio
On Tue, Nov 18, 2008 at 7:28 PM, Sander van Zoest [EMAIL PROTECTED]wrote: By the way, the pixel-aspect-ratio on video caps in the GStreamer framework has precisely the same meaning as this attribute, overriding it on a video sink also has an effect similar to what is suggested in the HTML5 spec. In other words, it's not so outlanding from a media framework's point of view. In the capture world it makes a lot of sense. You are converting analog content into digital. It is my understanding that HTML5 is presentation technology, not a video capture, transcoding or editing framework. Video capture is getting popular on the Web, so it would not be surprising to see HTML5 extend in that direction in the future. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] video tag: pixel aspect ratio
On Thu, 13 Nov 2008, Pierre-Olivier Latour wrote: And the suggested hack is not even really usable: if you have a video coming from a NTSC DV source as 720x480 improperly transcoded to say MP4 720x480 square pixels, using the theoretical 10:11 pixel aspect ratio will _not_ make it look right: it needs to be clipped to 704x480 first. Are you sure? If you don't clip it, you still get the right shape pixels, don't you? You don't get the right final video size, sure, because you didn't crop, but so what? We're just trying to do a last-ditch aspect ratio fix here, not get perfect video. Pixel aspect ratio has a precise meaning in the video world, and using it outside of clean aperture does not make a lot of sense... As far as I can tell, using it outside clean aperture works fine so long as you don't also expect the final output to be the right video size. At the same time, saying that pixel ratio is intentionally ill-defined because we don't *really* want people to use it is also quite confusing. Right, that's the idea. :-) If we start going in this direction, then img should have a dpi attribute so you can hack around images uploaded at dpi 72 ;) We effectively do, it's the height (or width) attribute. In any case, if this attribute really needs to be present, we should rename it at the minimum (picking a term from the professional video world requires taking the constraints that come with it), maybe displayRatio or something? Maybe horizontalpixelstretchfactor? Personally I don't really see the problem with pixelratio. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video tag: pixel aspect ratio
On Thu, Nov 13, 2008 at 9:12 PM, Pierre-Olivier Latour [EMAIL PROTECTED]wrote: In any case, if this attribute really needs to be present, we should rename it at the minimum (picking a term from the professional video world requires taking the constraints that come with it), maybe displayRatio or something? If you are going to keep it, how about pixelfloat, as it clearly is not presented as a ratio. The word display makes me think DAR. -- Sander
Re: [whatwg] video tag: pixel aspect ratio
On Wed, 15 Oct 2008, Sander van Zoest wrote: source pixelratio=10:11 !-- 525 composite NTSC -- source pixelratio=59:54 !-- 625 composite PAL -- source pixelratio=1018:1062 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- Currently pixelratio is a floating point number, as in: source pixelratio=0.909090909 !-- 525 composite NTSC -- source pixelratio=1.09259259 !-- 625 composite PAL -- source pixelratio=0.958568738 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- Is that not enough? I hate to say it, but if it was enough, I wouldn't be commenting here. It simply isn't accurate enough to store it as a float. Every respected container stores the ratio as X x Y. See the PASP atom for example. On Wed, 15 Oct 2008, Anne van Kesteren wrote: How is not accurate? In terms of precision it shouldn't really matter... I agree with Anne here. I've left the spec as is. Note that the whole point here is to discourage people from using the attribute. Also, it is intended only for use by people who are trying to fix a broken video; they might not know the right value, so it doesn't really matter so much whether the value that is used is precise or not, just so long as it improves the video relative to what it would be if the value in the video data file itself was assumed. On Wed, 15 Oct 2008, Sander van Zoest wrote: We are talking video here. Precision is at its core. If you consider the majority of the broken video out on the net today a good example of what you want more of then, I see no reason to accurately define PAR. [...] you can not accurately convert video on the fly if you do not have the exact ratio. All this stems from the conversion from analog to digital and in the analog world we did a lot of funky tricks to make things work better on hardware of those days, but as our computers and electronics in general get faster and faster, putting in inaccuracies can cause for some seriously ill side effects, now and especially in the future. The whole point here is that the video is wrong, and the author is trying to apply a last-minute hack to improve it a bit. If performance is an issue, then encode the video correctly and don't use the attribute at all. On Wed, 15 Oct 2008, Jonas Sicking wrote: I think if we make the syntax really simple like: 1. Find the first ':' 2. Parse the value before as an integer 3. Parse the value after as an integer then adding a new syntax is pretty cheap. Of course having separate attributes is even cheaper. But if the 10:11 syntax is really common then I think it might help authoring to use it. The whole point is to discourage authors from using it, so actually we sort of _want_ it to not help authoring. :-) On Wed, 15 Oct 2008, Eduard Pascual wrote: The issue is that, for most (probably all cases), the limitations of representation of floating numbers are a guarantee that the value will be wrong. It is not the same 0.909090909 that 0.909090909090909090... and that wouldn't still be the same that 10:11. Assume that we have a video that is 1 video pixels square. That's a 100 megapixel video. If we pretend that aspect ratio of the pixels is 11:11, then the video will, at 1:1 zoom, take 1 horizontal pixels (and 1 vertical pixels). If we assume that the pixel ratio is 10:11 = 0.9090909090909090909090909, and we keep the vertical number of pixels at 1, then it will be (rounding to 0dp) 9091 pixels wide. If we assume that the pixel ratio is just 10:11 = 0.90909 then it will STILL be (rounding to 0dp) 9091 pixels wide. In practice, videos are much smaller and displayed on much smaller displays. So, with all due respect, why is it not enough? Although the difference may seem negligible, simple image scaling algorythms tend to yield horribel results for slight scaling (you can try to render a PDF document at 101% zoom to see what I'm speaking about; especially one with images). The alternative, bilinear or trilinear scaling, could be too much of a strain for video: there is a higly noticeable difference between running such algorythm once and running it 25 or 30 times each second. If we add to the mix that pages might be including several videos; that most probably there is also audio playing along with the video, the computation cost of decoding, and the fact that not every user on the web (probably, not even the majority of them) uses a high end computer; then scaling needs to be quick and simple enough to achieve decent rendering without mass-frying CPUs. Scaling a video to 9090 pixels wide or 9091 pixels wide isn't going to show the artifacts you are talking about. I still don't understand why the spec has to define each and every parser algorythm (IMO, it should only define the syntax, and then the implementation should define its own algorythm that parses that syntax as defined) We have to define the parsers because the syntax alone
Re: [whatwg] video tag: pixel aspect ratio
I agree that incorrectly encoded videos are annoying, but I don't think we should have this attribute at all because I don't think it passes the will it be commonly used smell test. I am also afraid that it will difficult to use correctly, since you frequently have to use clean aperture in conjunction with pixel aspect ratio to get the correct display size. For the videos we're talking about, just getting near the right ratio is probably all we can ask for -- we're not talking about professional video data here. We're talking misencoded YouTube videos where an embedder wants to fix the most egregious error before showing his friends the cat jumping off the side of the pool or something. I agree that this is just a hack attribute, and I agree that it isn't going to be widely used. But I think it will be used enough to justify its existence. There are a surprisingly large number of misencoded videos on the Web, and plenty of people who care. I don't see how people who can't properly transcode (the majority of users I guess), will know on the other hand which aspect ratio to use to fix the problem (or even think about using this fix). Maybe there'll be some JS libraries around to do this automatically on the fly, but I don't see how this would ever be consistent or reliable. The real fix would need to be done in their workflow or tool they use. Also wouldn't services like YouTube be able to auto-detect such videos and resize them anyway (uploaded QT movies should have all the necessary info embedded for instance, but even if it is missing, you can likely assume that a 720x480 video should be resized to 640x480 before being served)? And the suggested hack is not even really usable: if you have a video coming from a NTSC DV source as 720x480 improperly transcoded to say MP4 720x480 square pixels, using the theoretical 10:11 pixel aspect ratio will _not_ make it look right: it needs to be clipped to 704x480 first. Pixel aspect ratio has a precise meaning in the video world, and using it outside of clean aperture does not make a lot of sense... At the same time, saying that pixel ratio is intentionally ill-defined because we don't *really* want people to use it is also quite confusing. If we start going in this direction, then img should have a dpi attribute so you can hack around images uploaded at dpi 72 ;) In any case, if this attribute really needs to be present, we should rename it at the minimum (picking a term from the professional video world requires taking the constraints that come with it), maybe displayRatio or something? Pierre-Olivier Latour - [EMAIL PROTECTED] Rich Media Team - Apple, Inc.
Re: [whatwg] video tag: pixel aspect ratio
On Wed, Oct 15, 2008 at 8:14 AM, Anne van Kesteren [EMAIL PROTECTED] wrote: On Wed, 15 Oct 2008 17:01:22 +0200, Sander van Zoest [EMAIL PROTECTED] wrote: I hate to say it, but if it was enough, I wouldn't be commenting here. It simply isn't accurate enough to store it as a float. How is not accurate? In terms of precision it shouldn't really matter... We are talking video here. Precision is at its core. If you consider the majority of the broken video out on the net today a good example of what you want more of then, I see no reason to accurately define PAR. I won't get into Frame Rates such as 59.94Hz, since that is off topic here, but you can not accurately convert video on the fly if you do not have the exact ratio. All this stems from the conversion from analog to digital and in the analog world we did a lot of funky tricks to make things work better on hardware of those days, but as our computers and electronics in general get faster and faster, putting in inaccuracies can cause for some seriously ill side effects, now and especially in the future. Because of the conversion from analog to digital there are a lot of funky areas where you end up with a PAR/SAR that would be rounded inaccurately if expressed as a float. 2 32-bit integers is what is used today, with the hope that that will get us into a fully square pixel world, by the time the video quality gets good enough where we can no longer express PAR in 32-bit integers. For some background on this see http://lipas.uwasa.fi/~f76998/video/conversion/. I really do not want to add to the inaccuracies in the world, especially if we have a chance to do it right. There are already many of these types of mistakes in things like Media RSS, I wouldn't know how to accurately express the frame rate of a 30M clip in the framerate attribute of the content element. For some of the madness that we are talking about here, see http://groups.google.com/group/sci.engr.advanced-tv/msg/108815e3089c4d53?pli=1. I am sort of of the camp, if you are going to even provide pixelratio as an attribute, then at least do it like every other container format out there, rather then expressing it a manner that limits its use and forces inaccuracies caused by rounding and human error (because they do not understand why you want a 10 digit float). Take it for what it is worth. -- Sander
Re: [whatwg] video tag: pixel aspect ratio
Patterns may be ambiguous; an algorithm that is ambiguous would also be dubious and thus easily identified and rejected. Of course, patterns can be proven to be precise, but using explicit algorithms is safer. IMHO, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduard Pascual Sent: Wednesday, October 15, 2008 5:22 PM To: Ian Hickson Cc: whatwg@lists.whatwg.org; Sander van Zoest Subject: Re: [whatwg] video tag: pixel aspect ratio On Wed, Oct 15, 2008 at 10:40 AM, Ian Hickson [EMAIL PROTECTED] wrote: This isn't expected to be used often. It's really only provided to allow for simple override of the actual value in the video file, for when the video file is known to be wrong. I am very reluctant to make up a whole new microsyntax and corresponding parser algorithm, along with all the tests, etc, to handle this one case. I still don't understand why the spec has to define each and every parser algorythm (IMO, it should only define the syntax, and then the implementation should define its own algorythm that parses that syntax as defined); but if that's the issue then a microsyntax can be perfectly avoided by splitting the argument into two separate ones, such as pixelratiox and pixelratioy. Just my opinion.
Re: [whatwg] video tag: pixel aspect ratio
On Wed, Oct 15, 2008 at 2:40 AM, Ian Hickson [EMAIL PROTECTED] wrote: Is that not enough? It is enough. Sander and Eduard have provided excellent arguments why the pixel aspect ratio, and especially the frame rate, should be represented as rationals in video formats. But as an override for already broken video streams compliance to best practice does not justify another data type in html5. To put Anne's comment another way, one needs a gigapixel display device before the difference between 1.0925 (rounded to only 5 figures) and 59/54 affects the behaviour of the scaling algorithm at all. There aren't so many aspect ratios is common use--you're welcome to choose the one nearest to the floating point value given if you think it's important. -r -- Ralph Giles Xiph.org Foundation
Re: [whatwg] video tag: pixel aspect ratio
We could also say that specifying only one coordinate has no effect. I think the requirement that both attributes have to be present or absent cannot be specified in a document type definition (if someone would like to have one nevertheless). Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sander van Zoest Sent: Wednesday, October 15, 2008 6:35 PM To: Eduard Pascual Cc: whatwg@lists.whatwg.org; Ian Hickson Subject: Re: [whatwg] video tag: pixel aspect ratio On Wed, Oct 15, 2008 at 8:22 AM, Eduard Pascual [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 10:40 AM, Ian Hickson [EMAIL PROTECTED] wrote: snip I am very reluctant to make up a whole new microsyntax and corresponding parser algorithm, along with all the tests, etc, to handle this one case. I still don't understand why the spec has to define each and every parser algorythm (IMO, it should only define the syntax, and then the implementation should define its own algorythm that parses that syntax as defined); but if that's the issue then a microsyntax can be perfectly avoided by splitting the argument into two separate ones, such as pixelratiox and pixelratioy. The only issue I have with splitting it into separate ones, is that we need to ensure that both exist or none exist, having just X or just Y is clearly confusing and should not be allowed. -- Sander
Re: [whatwg] video tag: pixel aspect ratio
The user agent could calculate the best continued fraction approximation to recover the original ratio from the floating-point representation. That means the denominator should be limited somehow. Otherwise, the attribute could be split into two in order to avoid the microsyntax. The resulting attributes are guaranteed to have ugly names though. pixelratiowidth and pixelratioheight are better than pixelratiox and pixelratioy because they have the advantage of being readable. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Wednesday, October 15, 2008 11:41 AM To: Sander van Zoest Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] video tag: pixel aspect ratio On Tue, 14 Oct 2008, Sander van Zoest wrote: I just recently started looking at HTML5 and noticed the video tag. Neat addition. I also noticed that it as an attribute named 'pixelratio', however, as you know this is never an integer, but rather is the result of a fraction (i.e. ratio). As for proper playback of video frames, it is important to understand exact float and therefore I would suggest either expressing it as a ratio of two 32-bit integers separated by a colon (or slash) or use two different attributes. This avoids unintentional rounding. Something roughly along the lines of: source pixelratio=10:11 !-- 525 composite NTSC -- source pixelratio=59:54 !-- 625 composite PAL -- source pixelratio=1018:1062 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- Currently pixelratio is a floating point number, as in: source pixelratio=0.909090909 !-- 525 composite NTSC -- source pixelratio=1.09259259 !-- 625 composite PAL -- source pixelratio=0.958568738 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- Is that not enough? This isn't expected to be used often. It's really only provided to allow for simple override of the actual value in the video file, for when the video file is known to be wrong. I am very reluctant to make up a whole new microsyntax and corresponding parser algorithm, along with all the tests, etc, to handle this one case.
Re: [whatwg] video tag: pixel aspect ratio
On Wed, Oct 15, 2008 at 11:11 AM, Ralph Giles [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 2:40 AM, Ian Hickson [EMAIL PROTECTED] wrote: Is that not enough? It is enough. Sander and Eduard have provided excellent arguments why the pixel aspect ratio, and especially the frame rate, should be represented as rationals in video formats. But as an override for already broken video streams compliance to best practice does not justify another data type in html5. Is an integer another data type? Also, having non-square pixels is not broken. If we go this route, we might as well get rid of the distinction all together. To put Anne's comment another way, one needs a gigapixel display device before the difference between 1.0925 (rounded to only 5 figures) and 59/54 affects the behaviour of the scaling algorithm at all. There aren't so many aspect ratios is common use--you're welcome to choose the one nearest to the floating point value given if you think it's important. I do not see why we are condoning hacks on top of hacks, when it is so simple to just specify hSpace and vSpace. -- Sander
Re: [whatwg] video tag: pixel aspect ratio
On Wed, Oct 15, 2008 at 12:04 PM, Sander van Zoest [EMAIL PROTECTED]wrote: I do not see why we are condoning hacks on top of hacks, when it is so simple to just specify hSpace and vSpace. The entire problem is that it is not simple. It is less simple to spec, less simple to declare, less simple to parse, and less simple to test, and there is zero real-world gain in it. It is not a hack to note that the floating-point precision available here is far higher than what any display could ever manage and therefore any rounding errors occur at levels many orders of magnitude to small to have any effect at all. PK
Re: [whatwg] video tag: pixel aspect ratio
The entire problem is that it is not simple. It is less simple to spec, less simple to declare, less simple to parse, and less simple to test, and there is zero real-world gain in it. sarcasmOh! Then just drop video completly. Better, drop html5 and there will be even less trouble with specifications./sarcasm If you can come up with a argument that supports a float value, like a real world use case, other than we don't feel like editing the spec to add better, more robust functionality, then you have my support :)
Re: [whatwg] video tag: pixel aspect ratio
On Oct 15, 2008, at 1:04 PM, Ralph Giles wrote: On Wed, Oct 15, 2008 at 12:31 PM, Sander van Zoest [EMAIL PROTECTED] wrote: Following that logic, why add the attribute at all? Well, I like the pixelaspect attribute because incorrect aspect ratios drive me up the wall. Because the video and its embedding page are often served from different locations, it's nice to have a way to fix it the doesn't require editing the video file. I agree that incorrectly encoded videos are annoying, but I don't think we should have this attribute at all because I don't think it passes the will it be commonly used smell test. I am also afraid that it will difficult to use correctly, since you frequently have to use clean aperture in conjunction with pixel aspect ratio to get the correct display size. For example (you probably know this, but for the benefit of others following the discussion) DV NTSC video is 720x480, has Rec.601 aspect ratio (10:11), and should be displayed at 640x480. Multiplying 720x480 by 10:11 doesn't give 640x480 however, you have to crop to clean aperture (704x480) first. We *definitely* don't want to expose CLASP. I don't think it should be included in the first version of the spec. eric
Re: [whatwg] video tag: pixel aspect ratio
Anne van Kesteren wrote: On Wed, 15 Oct 2008 17:01:22 +0200, Sander van Zoest [EMAIL PROTECTED] wrote: I hate to say it, but if it was enough, I wouldn't be commenting here. It simply isn't accurate enough to store it as a float. How is not accurate? In terms of precision it shouldn't really matter... Every respected container stores the ratio as X x Y. Ian, you could generalize the algorithm for link sizes and use that I suppose. I think if we make the syntax really simple like: 1. Find the first ':' 2. Parse the value before as an integer 3. Parse the value after as an integer then adding a new syntax is pretty cheap. Of course having separate attributes is even cheaper. But if the 10:11 syntax is really common then I think it might help authoring to use it. / Jonas
Re: [whatwg] video tag: pixel aspect ratio
On Wed, Oct 15, 2008 at 2:48 PM, Eric Carlson [EMAIL PROTECTED]wrote: On Oct 15, 2008, at 1:04 PM, Ralph Giles wrote: On Wed, Oct 15, 2008 at 12:31 PM, Sander van Zoest [EMAIL PROTECTED] wrote: Following that logic, why add the attribute at all? Well, I like the pixelaspect attribute because incorrect aspect ratios drive me up the wall. Because the video and its embedding page are often served from different locations, it's nice to have a way to fix it the doesn't require editing the video file. I agree that incorrectly encoded videos are annoying, but I don't think we should have this attribute at all because I don't think it passes the will it be commonly used smell test. I am also afraid that it will difficult to use correctly, since you frequently have to use clean aperture in conjunction with pixel aspect ratio to get the correct display size. For example (you probably know this, but for the benefit of others following the discussion) DV NTSC video is 720x480, has Rec.601 aspect ratio (10:11), and should be displayed at 640x480. Multiplying 720x480 by 10:11 doesn't give 640x480 however, you have to crop to clean aperture (704x480) first. We *definitely* don't want to expose CLASP. I don't think it should be included in the first version of the spec. Certainly not. I forgot about the required crop. I am now even more convinced it doesn't belong in the spec. Let the container handle this detail. -- Sander
[whatwg] video tag: pixel aspect ratio
Hi, I just recently started looking at HTML5 and noticed the video tag. Neat addition. I also noticed that it as an attribute named 'pixelratio', however, as you know this is never an integer, but rather is the result of a fraction (i.e. ratio). As for proper playback of video frames, it is important to understand exact float and therefore I would suggest either expressing it as a ratio of two 32-bit integers separated by a colon (or slash) or use two different attributes. This avoids unintentional rounding. Something roughly along the lines of: video pixelratio=10:11 !-- 525 composite NTSC -- video pixelratio=59:54 !-- 625 composite PAL -- video pixelratio=1018:1062 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- video parhSpacing=10 parvSpacing=11 Container formats tend to store this information in a ratio like this and not in a float. Best, -- Sander van Zoest [EMAIL PROTECTED] San Diego, CA, USA http://Sander.vanZoest.com/
Re: [whatwg] video tag: pixel aspect ratio
On Tue, Oct 14, 2008 at 9:39 AM, Sander van Zoest [EMAIL PROTECTED]wrote: Hi, I just recently started looking at HTML5 and noticed the video tag. Neat addition. I also noticed that it as an attribute named 'pixelratio', however, as you know this is never an integer, but rather is the result of a fraction (i.e. ratio). As for proper playback of video frames, it is important to understand exact float and therefore I would suggest either expressing it as a ratio of two 32-bit integers separated by a colon (or slash) or use two different attributes. This avoids unintentional rounding. Something roughly along the lines of: video pixelratio=10:11 !-- 525 composite NTSC -- video pixelratio=59:54 !-- 625 composite PAL -- video pixelratio=1018:1062 !-- 1920x1035 HDTV SMPTE RP 187-1995 -- video parhSpacing=10 parvSpacing=11 Container formats tend to store this information in a ratio like this and not in a float. Please excuse me for referencing the video tag as, after further reading, it is apparent that the pixelratio attribute is applied to the source tag. Regardless, I believe the same points apply, so therefore please mentally /video/source/ . Thank you and sorry for the confusion and stress I may caused. -- Sander
