Re: [whatwg] video tag: pixel aspect ratio
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? 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 behaves like by default and have a special attribute to scale proportionally, - or should 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 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. ____________ Pierre-Olivier Latour - [EMAIL PROTECTED] Rich Media Team - Apple, Inc.
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 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, by , "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
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 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.
