View Full Version : Aspect Ratio Problem When Uploading to YouTube


Sie Callebs
August 19th, 2010, 11:37 AM
I am trying to get some dance recital clips posted to YouTube. We shot this recital with three Sony FX1 cameras in DV Widescreen mode and I am using Sony Vegas to edit. When I upload the clip to Youtube, it looks somewhat squeezed in -- perhaps not 4:3, but definitely not the widescreen format we used for the shoot. In my Vegas project, under Options > Preferences > Video Device, I have it set to NTSC DV Widescreen, and when I render the .avi file, I set the template to NTSC DV Widescreen. But apparently I'm doing something wrong.

Here's a very short clip that I uploaded -- it's only a few seconds long because my upload speed is slow and I didn't want to waste hours uploading the whole clip if the aspect ratio was wrong. But you can see what I mean about the video not filling YouTube's whole 16:9 screen:

http://www.youtube.com/watch?v=p6xuisH4vPE

Any tips or suggestions would be greatly appreciated.

Thanks in advance!

John Cline
August 19th, 2010, 01:29 PM
NTSC DV has an image dimension of 720x480 regardless of whether its widescreen or not. For widescreen, it squeezes the widescreen 16:9 image horizontally to fit within 720x480 and then sets a flag in the video's header to tell the playback device to expand it back out to widescreen for display. Welcome to the world of non-square pixels.

YouTube (and most media players) don't know anything about this widescreen flag, they just assume that every video should be displayed at the file's image dimensions. You need to render out in widescreen image dimensions. But first go to "File" > "Project Properties" and check that the "Deinterlace method" in the "Video" tab is set to something other than "None." I suggest setting it to "Interploate." Go to the "Audio" tab and set the "Resample and Stretch quality" to "Best."

Now, if you're using v9.0, use "Sony AVC" as the render type, select the "Internet 4:3 SD 30P" template. Hit the custom button and change the frame size to "Custom" and enter "854" for the width and "480" for the height. The default bit rate might be a little low for excellent video quality, so you might want to set it to "4,000,000." Of course, this will make the file larger and will take longer to upload, but it will look better. Go to the "Audio" tab and set the sample rate to "44,100." Save this template as "Internet 16:9 SD 30P" and start your render. Upload this file to YouTube and you're all set.

Sie Callebs
August 19th, 2010, 04:36 PM
Thanks, John.

I'm still stuck in the stone age using Vegas 6 (I really need to upgrade), and I don't see an option for the "Internet 4:3 SD 30P" template. The only template I see that will let me create a custom frame size is "NTSC DV YUV." I'll try out some of the other settings you recommended and see if I can render out a file that will look correct on YouTube.

John Cline
August 19th, 2010, 05:11 PM
Rendering to an uncompressed NTSC YUV .AVI will be far too large in file size to upload to YouTube.

You can also use Windows Media Video (WMV) files instead of Sony AVC. Choose something like the "3Mbps Video" template and change the frame size to 854x480 and change the frame rate to 29.97 instead of 30. That should get you there. You can also hange the bitrate from "3 M" to "4 M" or even "5 M" (The "M" stands for millions of bits.)

Robert Martens
August 19th, 2010, 06:20 PM
YouTube (and most media players) don't know anything about this widescreen flag...

I hate to be so blunt about this, but yes, they do; Youtube, and most media players, correctly interpret either pixel aspect or display aspect ratios, assuming they've been properly flagged. Whether playing back with Windows Media Player, Media Player Classic, VLC and Quicktime Player, for example, or uploading to Youtube or Vimeo, I've never had a problem with a correctly encoded MP4 or MKV; the problem here is likely the AVI container, which has no such AR tagging facility. The information can be added to the bitstream, in some cases, and I've successfully achieved this with MPEG-4 Part 2 and Part 10 streams packed into AVIs, but frankly I'm not sure how one would achieve that from Vegas.

Sie, I see you've since removed the video from your account, but for future reference you can address this issue in limited fashion even after upload, by following these steps: Formatting tags : Learn More - YouTube Help (http://www.google.com/support/youtube/bin/answer.py?hl=en&answer=146402) You'd want the yt:stretch=16:9 tag for the stated example, if I'm not mistaken.

Why Youtube doesn't make a greater effort to publicize those tags, and perhaps expand the functionality, is beyond me.

John Cline
August 19th, 2010, 06:48 PM
I hate to be blunt back at you, but he uploaded an NTSC DV format .AVI file which does have a PAR flag. Despite what you say, some media players don't handle the PAR flag correctly, if at all. If you want a widescreen SD file to upload to YouTube then it is best to simply encode it at the proper image dimensions and then the PAR flag doesn't matter.

Jeff Harper
August 20th, 2010, 01:18 AM
Optimizing your video uploads : Learn More - YouTube Help (http://www.google.com/support/youtube/bin/answer.py?hl=en&answer=132460)

Sie, when I first read your post, it occurred to me that you should have simply checked with YouTube help...and gotten some ideas directly from them. I don't know about tags, etc., but if you upload the video according to the page linked above you shouldn't need tags. Just render to MPEG 2 and Youtube should retain the original dimensions of the video.

Seth Bloombaum
August 20th, 2010, 10:50 AM
There are so many player / distribution codec combinations that don't correctly interpret PAR flagging that it seems to me the only reasonable choice is to distribute in square-pixel formats only, unless one is going to DVD-Video, where there is a standard for PAR flagging.

I'm glad that Youtube has an internal flagging method for their transcoder... but, nevertheless, my experience has been that distributing clips with a 1.0 PAR is essential to reliable online distribution. Granted, this might not be as important to someone who works only with Youtube and has a good workflow, but many people are working with YT, Vimeo, Exposure Room, their own embedded Flash player, WMP, QT, etc., and square pixels take care of so many problems before they start!

And don't get me started on QT - even using DI on a single Mac between FCP, Compressor, and iDVD the PAR flagging is a huge source of frustration. Square pixels help me keep what hair I have left...

Robert Martens
August 20th, 2010, 12:17 PM
Well, obviously I've been grossly misinformed with regard to the majority of media players; without trying to be a passive aggressive smartass (which, hard as it may be to believe, was my honest intent with "I hate to be so blunt" earlier), what particular combinations have you guys found troublesome? DV AVIs are the only things I've had this trouble with, what is everyone finding so unreliable as far as pixel and/or display aspect ratio tagging?

Seth Bloombaum
August 20th, 2010, 12:50 PM
This is sort of general, because at times PAR flagging seems to work with a particular player/container/codec combination, and sometimes it doesn't. That's what has led me to conclude that a best-practices approach is always square pixels, because it works reliably across them all.

Biggest troublemaker first:
QT container - some codecs work, some don't. Always seems to change with QT updates.
Keeping track of YT, Vimeo, XR; which is currently working, which is not.
Embedding one's own flash player, either an open-source solution or code from the full Flash Application.
I've even sometimes had problems with WMV - either the encoder didn't properly set the flag, or an embedded player didn't pick it up, especially when working with an HDV timeline.

With what I'm typically working with from day to day, the UGC online services and my embed of a Flash player have been the biggest headaches.

Then there are the students I support - multiply the problem 10x, my message to them becomes "simplify and standardize your workflow - do what you know works." Who has time to keep track of buggy PAR flagging?

Matteo Manson
August 21st, 2010, 02:33 AM
Definitely sounds like a PAR problem to me. I always use MP4 for youtube. Never had any PAR/AR issues before that I can recall.

Gerald Webb
August 22nd, 2010, 04:32 AM
just add 2c here,
as Seth said, the only way to go is square pixel, which for those who dont know, there is an easy way to change ANY project to square before rendering, and then you never have to worry about it again.

If using, say, PAL 720 x 576 widescreen, all you do is go,
File, Properties,
Pixel aspect ratio change from 1.4568 to 1 (square)
then change the width of your project to 1049, (720 x 1.4568= 1048.896 )

Your preview looks exactly the same but now you are in square pixels.
Now when compressing to H264 or FLV you dont have to worry about tags etc.

For NTSC it would be 720 x 1.2121=872.712 so your width would be 873.

It works for any out of square pixel, simplifies everything with compression.

Sie Callebs
August 22nd, 2010, 05:06 AM
Thnks for the tips, everyone. I had originally checked YouTube's help topics, but apparently didn't see the part about optimizing. I tried some of John's suggestions but couldn't get anything to work and gave up. I'll revisit the clip again today and see if I can't get it uploaded correctly.

Here's one of the original clips I uploaded, I tagged them as "unlisted" on Youtube since they are test clips and I didn't need everyone to see them. The aspect ratio on this clip seems to have changed and now fills the screen, but still looks squeezed in:

YouTube - BugleBoy2 (http://www.youtube.com/watch?v=3NphdlTJLJg)

Another short clip where I changed the frame size in the project properties. This one came closer to looking right, but still had some black borders:

YouTube - Dance (http://www.youtube.com/watch?v=cjmPX6PQ8Nw)

Edward Troxel
August 22nd, 2010, 06:13 AM
then change the width of your project to 1049, (720 x 1.4568= 1048.896 )

For NTSC it would be 720 x 1.2121=872.712 so your width would be 873.


Aren't the width and height supposed to be a factor of 8? Meaning you should really use 1048 and 872 in these examples instead?

Sie Callebs
August 22nd, 2010, 06:15 AM
OK, I'm frustrated again.

I looked at Youtubes tips on optimizing video uploads, and, for widescreen videos, thay say "Upload a 16:9 video at its original aspect ratio (1280x720 recommended)" Sounds great! But when I click on properties in my Vegas project, it says the dimensions are 720 x 480. I tried changing this to 1280 x 720 and it didn't work. I tried setting the width to 873 as Gerald suggested and it didn't work.

I wanted to upload the clip in .avi format to maintain the best quality (Youtube also suggests uploading the video in its original format), but I also tried rendering in mpeg2 to see if that had any effect.

Here are some of the clips I uploaded. These are brutally short, since I just wanted to see what the aspect ratio looked like and my upload speed is slow as mentioned earlier. I named some of the clips according to the settings I rendered them under. Nothing has looked right so far, unless I viewed the clip before YouTube had completely finished with the processing and it has changed since then.

YouTube - BugleBoy1280720 (http://www.youtube.com/watch?v=t0yY3W375s4)

YouTube - BugleBoympg43 (http://www.youtube.com/watch?v=DtCOqM5RFAo)

YouTube - BugleBoyCC (http://www.youtube.com/watch?v=gDv2p_Bz8ns)

YouTube - BugleBoy873 (http://www.youtube.com/watch?v=W8d2VaxdysY)

YouTube - BugleBoy5 (http://www.youtube.com/watch?v=R5vMvgRsRXw)

YouTube - BugleBoyPixel (http://www.youtube.com/watch?v=CFyNFavJNW8)

YouTube - BugleBoy1280 (http://www.youtube.com/watch?v=5qMQIhd7Yr8)

I guess if nothing else, I can render with the aspect ratio set to 4:3 and the clips will have the letterboxing bars and the pillar bars on the sides, but at least the aspect ratio will be correct.

Something tells me I'm making this whole process much more difficult than it needs to be.

Edward Troxel
August 22nd, 2010, 06:29 AM
1280x720 is HD while 720x480 is SD. You wouldn't try to convert your SD video to HD before uploading.

Sie Callebs
August 22nd, 2010, 07:26 AM
That makes sense.

I'm in the process of uploading the whole clip in mpeg format, using the following tag while the video is uploading, as YouTube suggests:

yt:crop=16:9

According the the Help Forum, this will zoom in on the 16:9 image and fill Youtube's screen (not sure if that means there will be a bit of quality loss). If that works, I'll upload it again in .avi format using the same tag.

Sie Callebs
August 22nd, 2010, 07:50 AM
That seems to have worked, though it looks to me like there's still a bit of vertical "squeezing." Also, the audio was disabled due to WMG copyrights (which I should've anticipated). I'm not really happy with the mpeg quality either, but will try uploading an .avi file and use only the camcorder audio without the studio track laid underneath, maybe it will get past YouTube's copyright filter.

Here's the full clip, for anyone who cares to view it and likes silent movies:

YouTube - BugleBoy (http://www.youtube.com/watch?v=2hPGzRuliPo)

Thanks to everyone here who chimed in to help.

Gerald Webb
August 22nd, 2010, 02:59 PM
Aren't the width and height supposed to be a factor of 8? Meaning you should really use 1048 and 872 in these examples instead?

I read that somewhere as well Ed, but since I'd already been doing this and never had any problems with it I just stuck with the math, and kept doing it that way.
What is the reason behind the multiples of 8 ( or 4 as I read ), and downside of not complying with it?

Edward Troxel
August 23rd, 2010, 06:38 AM
I'm guessing because a byte is 8-bits and so multiples of 8 properly fill up bytes.

Robert Martens
August 23rd, 2010, 02:37 PM
Video is compressed not by individual pixels, but in chunks known as "macroblocks"; traditionally these have been 16x16 or 8x8, though other sizes aren't unheard of. If you compress to a resolution where one, or both axes are not multiples of the macroblock size along said axis, the image gets padded with garbage (the reason for the padding is beyond me, but I suspect it's because of what Ed said above). The end result being that part of your bitrate is now going toward encoding that garbage, where a video matching block multiple sizes will dedicate the full data rate to the content.

The conventional recommendation is to stick to multiples of 16, though it seems more modern codecs use 8 unit blocks, but either way it's not the end of the world these days. Still nice to try and follow the rule, but at higher bitrates, destined for local playback or broadband delivery, there's not an enormous quality hit from using 640x360 instead of 640x352, 1920x1072 instead of 1920x1080, or any other resolution that's not mod 16, so you may not see a benefit from making the effort.