Last modified: 2011-06-14 20:10:29 UTC
Uploading a copy of the 'Shuttle flip.webm' from the prototype page to my local test wiki with transcoding working, I end up with two playable file versions: "WebM source" at the original 1080x608 "WebM 480P" -- which is actually sized at 640x360 Since HD video formats are defined by their height, not their width, it might be better to go ahead and size "480P" to 480 pixels high and "720P" to 720 pixels high etc, rather than "480P" to 640 pixels *wide* and 720P to 1280 pixels wide. A 480P transcode of a 16:9 file should probably either be 854x480 (square pixels), or else use 720x480 and tweak the aspect ratio. Note that a 360 pixels-high file would not be terribly in plenty of circumstances, but should be labeled as 360P.
Similarly, the 1920x1088 sample file creates a '720p' file at 1280x726 and a '480p' file at 640x362: http://prototype.wikimedia.org/tmh/images/b/b2/File-Arborophila_brunneopectus_pair_feeding_-_Kaeng_Krachan.ogv (Some digital cameras produce movies at 1920x1088 resolution as 1080 is not divisible by 16 and I guess their compression chips prefer it.)
Also I'm seeing 1280x726 in .ogv output but 1280x725 in .webm and the .jpg snapshots. Sizes should probably be consistent across all output formats at same size.
yea these complications are caused by trying to use the concept of "maxSize" so its geared against the larger size.. if we just use the height.. there is no control against a very very long video. But I agree it would be nice to be consistent with what we are tagging videos. i.e 720P should be 720 high regardless of if its corresponding width is 1280 wide or 1269 in the case that you described. In extreme cases a 3x4 video will be much less pixels than 720 width metric. Where people have more time an energy for such things, they have separate profiles and bitrates for 3x4 than they do for 16x9 but I think we can get away with just setting height and [auto] width, so that it correlates better with our video tags / names. And then maybe put in a sanity check that beyond that. Something like height=>720 maxWidth=>1400 --michael
For videos wider than 16:9, I'd generally be inclined to treat them as though they belong in letterboxed 16:9 so we're producing something that fits standard HD resolutions when blown up to full size. That'd basically mean scaling anything _narrower_ than 16:9 up to the full height (480, 720, 1080) and making them less wide, while scaling anything _wider_ than 16:9 up to the HD width (854?, 1280, 1920) and giving it a smaller height (eg 1280x544 for a 2.35 clip). This probably mostly should work ok with our existing box scaling model where we can say 'give me something that fits in 1280x720' and it fits the biggest side available (of course with the exception that we don't have an arbitrarily-open set of sizes. ;) Should double-check how YouTube treats funny-sized HD videos...
1088 is rather common, but wrong. All movies that produce 1088 SHOULD also have metadata that defines that their Display box should be 1920x1080 (cropped image of the recording basically). If they don't than issues such as you describe are simply expected behavior. So what youtube does with some uncommon source material: Youtube with 2.39:1 1920x800 source material http://www.youtube.com/watch?v=O574YXXSTb0 Their 1080p of this movie is: main debug: pic render sz 1920x800, of (0,0), vsz 1920x800, 4cc I420, sar 1:1, msk r0x0 g0x0 b0x0 main debug: pic in sz 1920x800, of (0,0), vsz 1920x800, 4cc I420, sar 1:1, msk r0x0 g0x0 b0x0 main debug: pic out sz 1920x800, of (0,0), vsz 1920x800, 4cc UYVY, sar 1:1, msk r0x0 g0x0 b0x0 It is rendered boxed in a 16:9 frame HD 1080p (16:9)== 1920x1080 HD 1080p (2.39:1) == 1920x800 (actual factor is 2.40:1, due to rounding) So this was kept 'as is' Youtube with 1440x608, 2.35:1 source material http://www.youtube.com/watch?v=RYX4aXyqx4g This qualifies as a weird format. actual 2.35 would have been 612 pixels high, so i'm guessing this was cropped down to 608 in order to be 16 pixel compatible Their 720p of this movie is: main debug: pic render sz 1280x540, of (0,0), vsz 1280x540, 4cc I420, sar 1:1, msk r0x0 g0x0 b0x0 main debug: pic in sz 1280x540, of (0,0), vsz 1280x540, 4cc I420, sar 1:1, msk r0x0 g0x0 b0x0 main debug: pic out sz 1280x540, of (0,0), vsz 1280x540, 4cc UYVY, sar 1:1, msk r0x0 g0x0 b0x0 It is rendered as boxed in a 16:9 frame. HD (720p) == 1280x720 actual DAR of produced image is 2.37:1 But clearly, 720p is not always 720 lines. It is always 1280 columns, with the DAR of the source video. So their conversion targets are the bounding boxes of 16:9 1080p/720p/480p/360p/240p video frame sizes, keeping the source display aspect ratio intact.
Youtube has some nice feature btw that we can consider: For instance: http://www.youtube.com/watch?v=G-XViSEyYHA This is a 4:3 640x480 source video. When you look at the Youtube conversions with VLC you will see that the display aspect ratio (or actually the Pixel aspect ratio) is incorrect. In the video options of Youtube, you can correct this problem by setting the option "stretch" to 16:9. Now the incorrect PAR is corrected with a compensated DAR in the video player. The visitors to the Youtube page never realize that the video source is not really correct. Same for a zoom option. http://www.youtube.com/watch?v=PkEaYCkpEB8 Source (and converted) material actually contain black letterboxing. The uploader has set the zoom option to 16:9 and you never notice the problem in the Youtube video player. Could be done for HTML5 video using CSS transformations: http://isithackday.com/hacks/videozoomandrotate/
Fixed encode sizes to match the logic described in #c4 in r90077
