Unlisted Bug? Track Motion Changes on Renders

Jonathan Neal wrote on 9/23/2006, 7:21 PM

Over at SCVUG, someone was asking about creating a video with 4 PIP which transitions with a clock wipe. So, I set to work and created 4 cells (upper left, upper right, lower left, lower right) which transition as a clock wipe sweeps around the entire video.

Then I discovered an interesting error; each of the four cells suddenly had black borders in my rendered WMV. I have two example Vegas 7 *.veg projects to demonstrate this. Render small portions of either clip in MPEG or AVI, and then render those same portions in WMV.

Clock Wipe

Star Wars Crawl

In Clock Wipe, each of the four cells will have black borders which are never present in the Video Preview window nor in the rendered MPEG or AVI.

In Star Wars Crawl, the second set of text will be severely off cue, which you will see in neither the Video Preview, MPEG, or AVI.

(edit, support question submitted)

Comments

Spot|DSE wrote on 9/23/2006, 8:15 PM

square pixels vs non-square pixels... As far as the StarWars being off-cue, no idea. I didn't download your veg files though. same framerate? Or are you changing out framerate in the WMV encode?

FrigidNDEditing wrote on 9/23/2006, 8:17 PM

in situations like this I would first suggest that you make sure you are previewing in "Good Quality -> Full"

if that doesn't take care of it, then I don't know for sure that WMV files use a different PAR than NTSC DV. I don't think that would make much of a dif in this case, but it's possible.

Dave

(EDIT)
It's gotta be the PAR (PIxel Aspect Ratio) It would appear that the PAR is being independantly applied to all the media in the project as it's being rendered?

FrigidNDEditing wrote on 9/23/2006, 8:38 PM

It's the way that Vegas applies the PAR to each feed independantly in your project. The work around (so strange to make workarounds in Vegas) is to nest the project. This then makes vegas see it as a single video feed and the gaps are gone.

Dave

(EDIT)
This solution is courtesy of a Glenn Chan Brain Storm

Jonathan Neal wrote on 9/23/2006, 8:42 PM

I've done some more tests. FrigidNDEditing, yes, I work in Good (full) mode which is also the same mode I render in. So you know, my project is in NTSC DV 24p (720x480, 23.976 fps). Some of you may be surprised and/or disappointed with the results.

First test, I rendered from 2:00 to 4:00 in MainConcept MPEG-2 (*.mpg) using the template DVD Architect 24p NTSC video stream.

The result was a video which perfectly matched the project and Video Preview.

Second test, I rendered the same 2:00 to 4:00 in MainConcept MPEG-2 (*.mpg) using the template DVD Architect 24p NTSC video stream, but this time I went into Custom and changed Aspect Ratio from 4:3 Display to Square pixels to experiment with what Spot/DSE called square pixels vs non-square pixels.

The result was a video stretched differently than the project, but without any borders between cells.

Third test, I rendered the same 2:00 to 4:00 in Video for Windows (*.avi) using the template NTSC DV 24p (inserting 2-3 pulldown).

The result was a video which perfectly matched the project and Video Preview, just as the MPEG rendered video had.

Fourth test, I rendered the same 2:00 to 4:00 in Video for Windows (*.avi) using the template NTSC DV 24p (inserting 2-3 pulldown), but this time I went into Custom and changed Pixel aspect ratio from 0.9091 to 1.0000 to experiment with what Spot/DSE called square pixels vs non-square pixels.

The result was a video stretched differently than the project, but without any borders between cells, just as the MPEG custom rendered video had.

Fifth test, I went to render the same 2:00 to 4:00 in Quicktime 7 (*.mov) using the template Default Template (uncompressed), but this crashed Vegas. Ut oh. I tried again using the template 56 Kbps Video, but this also crashed Vegas. Ut oh, ut oh. We'll just move on to the next test.

Sixth test, I rendered the same 2:00 to 4:00 in MainConcept AVC/AAC (*.mp4) using the template Default Template.

Tada, the borders appear! I go back and inspect Default Template to discover the Pixel aspect ratio is set to 1.0000.

Seventh test, I rendered the same 2:00 to 4:00 in MainConcept AVC/AAC (*.mp4) using the template Default Template, but this time I went into Custom and changed Pixel aspect ratio from 1.0000 to 0.9091. This should solve the border issue if pixel aspect ratios are goofy.

Ut oh, the borders are still there, this time thicker than ever! Now I'm clueless as to the consistency of Pixel aspect ratios between Vegas' rendering formats.

Jonathan Neal wrote on 9/24/2006, 10:55 AM

I've submitted this to Support.

When rendering to MP4 or WMV, any custom track motion is severely altered from what the video preview suggests (even at Good: Full). I was under the impression that this bug only had to do with differing pixel aspect ratios between my project and my rendering, however, the error does NOT occur when I render to AVI or MPEG with differing pixel aspect ratios, only MP4 or WMV. Am I doing something wrong to cause this?

Has anyone else tested this? Do I really have to use a work around as FrigidNDEditing suggested?

Spot|DSE wrote on 9/24/2006, 11:08 AM

It's not a "bug" per se...Vegas operates off the project properties. You're bringing in various PAR, which one is correct, if any of them?
So, you've brought in 1.212, 1.333, .909, and 1.0 PAR to the project. What are the project settings, and how should Vegas manage each one, as soon as you're outputting to yet another PAR?
Many applications have this "bug" if you would like to consider it as such, but the better means is to either edit your project in the output format aspect ratio, or use the Stretch option in the render dialog.
A script can also be used to change all the media to the output format, and overall, this is pretty easy to deal with once you start understanding output formats and PAR. Do everything in square pix as a project level, you'll never have this issue, but it can cause other kinds of grief.

Jonathan Neal wrote on 9/24/2006, 11:28 AM

Spot/DSE, thanks for the reply and asking good questions, I really appreciate your input on this subject. I've learned over my course of time posting on this forum that you are a good Vegas Guru to have around. Hopefully I will give you some good answers now too :)

You're bringing in various PAR, which one is correct, if any of them?
One of them is correct, and the PAR issue is inconsistent between formats. Various PARs react differently when rendering to different formats. Going from a 0.909 Project PAR to a 1.000 Render Par in AVI or MPEG will give you a different result than going from a 0.909 Project PAR to a 1.000 Render Par in MP4 or WMV. AVI and MPEG got it right, so that would be my best answer to which one is correct.

What are the project settings, and how should Vegas manage each one, as soon as you're outputting to yet another PAR?
In my first reply to this thread I thoroughly described my project settings and rendering options. Vegas managed the PAR discrepancies fine between the project and AVI / MPEG rendering. The way they managed those discrepancies is the way they should manage PAR discrepancies for all formats. Simply put, what you see is what you should get.

I'd also like to mention that I've written quite a bit on the subject of DAR and PAR, and I've also created many of my own texts of pixel ratios for emulating famous aspect ratios, as well as understanding the affects of stretched pixels, and also the best methods of working between differing imports / projects / exports. If I am doing something wrong to cause these PAR discrepancies between the formats then I would like to know. Otherwise, I hope Vegas can match their successful method of PAR export used in AVI / MPEG, to the same method used when exporting to MP4 / WMV.