My example here are several any insight would be helpful.

Example 1: Shooting with an xl2 and capturing in Vegas.

Rendering out a clip uncompressed with the following parameters

Project properties: NTSC DV 24p (720x480, 23.976 fps)
Image: http://nationaleventphotography.com/1.jpg

results in a video clip that measures: 720x480
Image: http://nationaleventphotography.com/2.jpg

=================================================

Rendering out a clip with the following parameters

using the template NTSC DV where stretch to output frame is NOT checked
Image: Image: http://nationaleventphotography.com/3.jpg
Notice the above image 3 that the size is indicated in 2 variations: 640x480 and 720x480 What’s the deal here, which one is it?

Next scenario:
Rendering from Vegas NTSC DV Widescreen where stretch to output frame is NOT checked.
Image: http://nationaleventphotography.com/4.jpg
here you will see that the properties indicate that the video is again 2 sizes, 720x480 AND 853x480 again, which one is it?
This scenario leads me to believe that the video is being stretched and possibly degraded because of the stretching?

Is there any method to render the clips other uncompressed and maintain the 720x480 size.

I have also noticed that a clip opened up lets say in Quicktime player right after capture from the camera shows that the size is 720x480 AND 853x480
I’m getting confused here and need some insight.

Thanks

For the Quicktime player, Normal Size and Current Size is the size of the "player" not the size of the "media". Because your PC uses square pixels Quicktime will also report these sizes in square pixels (i.e., each pixel is 1.0 high and 1.0 wide). The actual source does not use square pixels. DV is 720x480 with a pixel aspect ratio (PAR) of 0.9091 (not 1.0 which would be 655x480 in square pixels because 720 * 0.9091 = ~655). DV Widescreen is 720x480 with a PAR of 1.2121 which is 873x480 in square pixels (720 * 1.2121). That's why sometimes it reports 873x480 for DV widescreen video.

Nowhere in that Quicktime window you captured is the PAR displayed which causes the numbers to be confusing. The video is not being stretched, it is the aspect ratio of the pixels that causes the numbers to be reported differently.

~jr

For the Quicktime player, Normal Size and Current Size is the size of the "player" not the size of the "media". Because your PC uses square pixels Quicktime will also report these sizes in square pixels (i.e., each pixel is 1.0 high and 1.0 wide). The actual source does not use square pixels. DV is 720x480 with a pixel aspect ratio (PAR) of 0.9091 (not 1.0 which would be 655x480 in square pixels because 720 * 0.9091 = ~655). DV Widescreen is 720x480 with a PAR of 1.2121 which is 873x480 in square pixels (720 * 1.2121). That's why sometimes it reports 873x480 for DV widescreen video.

Nowhere in that Quicktime window you captured is the PAR displayed which causes the numbers to be confusing. The video is not being stretched, it is the aspect ratio of the pixels that causes the numbers to be reported differently.

~jr

I have just spent the last 3 hours rendering a single 4 second clip using every possible pixel aspect ratio, resolution, NTSC_DV, NTSC Standard, etc etc. It does not appear that Vegas can render out a wide screen MOV from a wide screen source.

I have tried changing the PAR to 1.212 and there is NO difference between this and 1.0. This was using "Frame Size: NTSC_DV 720x480 PAR = 1.0" The video looked exactly the same as when using "Frame Size: NTSC_DV 720x480 PAR = 1.212"

Why does Vegas (or the quicktime codec) ignore the PAR when encoding? Is the problem that I am choosing the NTSC_DV Frame Size, which over rides the PAR setting?

The ONLY way I have ever been able to get a Vegas render from a 16:9 project to look 16:9 on a computer monitor using Quicktime MOV was by nesting the 16x9 project inside a 4x3 project and then rendering out (using any PAR / frame size, because again Vegas or quicktime seems to pretty much ignore any of these settings).

Which brings me to the "stretch video to fill output frame (do not letterbox)" option. Vegas (or the quicktime codec) simply ignore this setting. Videos look the same with or with out it checked.

So why does "16x9 project + MOV = pain and suffering" with a nested veggies hack to get it to look correct?

And to make things still more annoying, using the WMV rendering, a 16x9 project file with the Defatult Template (which is full size @ 720x480) and a PAR of 1.0 gives what looks like a slightly wider image, but when compared side by side with the 4x3 nested Quicktime the 4x3 nested quicktime is just as wide, but not as tall.

IN other words, it appears that the only way to get what looks like a correctly proportioned wide screen image is to nest the 16x9 project inside a 4x3 project for BOTH the WMV and MOV codecs.

There has to be something I am missing here, right? I never have problems with the MPEG2 codecs, they always come out in the correct aspect ratio, but the PC codecs always seem to mangle the ratios.

And yet another addition to the perplexing MOV vs WMV rendering saga is that WMV9 default template vs Quicktime default template seems to make the MOV wash out the blacks and lost color saturation a little when compared side by side with the WMV.

Why does Vegas (or the quicktime codec) ignore the PAR when encoding?

I don't know why but as I said, the Quicktime player does not use any PAR other than 1.0 so you have to adjust your frame size to compensate.

Is the problem that I am choosing the NTSC_DV Frame Size, which over rides the PAR setting?

Yes, you should be using a custom frame size of 873x480 for the reasons I explained above.

The ONLY way I have ever been able to get a Vegas render from a 16:9 project to look 16:9 on a computer monitor using Quicktime MOV was by nesting the 16x9 project inside a 4x3 project and then rendering out (using any PAR / frame size, because again Vegas or quicktime seems to pretty much ignore any of these settings).

Try creating a custom template for Quicktime that uses 873x480 PAR 1.0 and your 16:9 footage should look exactly as you expect.

~jr

I don't know why but as I said, the Quicktime player does not use any PAR other than 1.0 so you have to adjust your frame size to compensate.
Yes, you should be using a custom frame size of 873x480 for the reasons I explained above.
Try creating a custom template for Quicktime that uses 873x480 PAR 1.0 and your 16:9 footage should look exactly as you expect.
~jr

Thank you very much. I suppose I'm more annoyed that Vegas doesn't know this and take care of it for you. Why didn't Vegas make a template for that out of the box? Seems like a rather important thing to do. And if Quicktime ignores all PAR settings, why doesn't Vegas gray out the related fields to avoid confusion (and me wasting a few hours!).

But thanks again John.

I suppose I'm more annoyed that Vegas doesn't know this and take care of it for you. Why didn't Vegas make a template for that out of the box?

There are lots of templates for Quicktime that are not there. There is no template for NTSC/PAL DV for example. This is probably because Quicktime is a native Apple format and AVI is a native Windows format. I guess they figure if you need more templates you can just make them so they only supply a small number of "web quality" Quicktime render templates.

It really depends on what you are going to do with the footage. For example, if you render to Quicktime widescreen with a PAR of 1.2121 and bring it back into Vegas and tell it that it's widescreen it will display perfectly. We do this in Ultimate S Pro when we prerender the lower thirds. This is not a Vegas issue... it's a Quicktime issue. Vegas handles the footage just fine.

And if Quicktime ignores all PAR settings, why doesn't Vegas gray out the related fields to avoid confusion (and me wasting a few hours!).

I'm not sure that Quicktime ignores the PAR settings, it is just the Quicktime Player that does. Vegas has no idea how you are going to use the footage. Graying options out would not be appropriate. As I said, we render the Ultimate S Pro lower thirds as Quicktime widescreen 720x480 PAR 1.2121 and they display fine in Vegas. So this particular problem of ignoring PAR is a Quicktime Player issue. There are lots of applications that ignore PAR and boldly (wrongly) assume that all video uses square pixels (particleIllusion comes to mind) so Vegas cannot possible know when to use PAR and when not to. You have to create templates that are appropriate for your targeted use.

~jr

I'm not sure that Quicktime ignores the PAR settings, it is just the Quicktime Player that does. Vegas has no idea how you are going to use the footage. Graying options out would not be appropriate. As I said, we render the Ultimate S Pro lower thirds as Quicktime widescreen 720x480 PAR 1.2121 and they display fine in Vegas. So this particular problem of ignoring PAR is a Quicktime Player issue. There are lots of applications that ignore PAR and boldly (wrongly) assume that all video uses square pixels (particleIllusion comes to mind) so Vegas cannot possible know when to use PAR and when not to. You have to create templates that are appropriate for your targeted use.
~jr

That makes more sense too. Thanks for all the explanations.

And by the way, I've just been going through the VASST Media Manager DVD, even though I swore I'd never use Vegas with the MM due to the extended load times instability I noticed from Vegas6. I have a wedding with 11hrs of footage to sort through and the MM is starting to be very handy for finding specific clips. The DVD is helping quite a lot to explain the MM. Thank you.

I have just spent the last 3 hours rendering a single 4 second clip using every possible pixel aspect ratio, resolution, NTSC_DV, NTSC Standard, etc etc. It does not appear that Vegas can render out a wide screen MOV from a wide screen source.

I've done this tons of times, with no problems. If my source project is 16:9, either NTSC DV widescreen, or HDV, I render using a custom Quicktime template of 640x360, or 848x480.

I don't ever touch the PAR settings. Vegas default settings are fine, and it handles the conversion among media with different PAR perfectly.