I've noticed some oddities akin to this just playing the T/L out.
I suspect if you put the HD on the top track and the HDV on the bottom track you may get a different result. Possibly Vegas doesn't realise that 1440x1080 does fill the frame.

Bob.

John, have you got this checked? Might be a good thing to do to check ON and then OFF and apply too. I have no idea if this SHOULD affect the issue of rendering, but it is a place to default-out the switch from the outset.



Grazie

I tested your project and got same result (Vegas Pro 13 Build 428). And if I reset Pan/Crop in the lower event (without deleting the event) render time speeds up a bit. And if I delete the event fx of the lower event it speeds up another bit and render time is 2:1 now.

Hmmm... that sample is too short for my system and VP13. I get less then a second in both cases.

Edit: I copied and past the clips 3 times to have 4 of each on the time line, still no go. It seems that the second render, most of the timeline is still in the cache or so because if I render the same setup, 2 tracks, twice I get already different times.

I would check what Grazie proposed and also check if you need Resample ON or OFF for the final render; since input and output are same frame rate and interlaced I would leave it off.

Vegas Pro 10
Both Tracks 17 seconds
Delete Event on bottom track 5 seconds

Vegas Pro 11
Both Tracks 7 seconds
Delete Event on bottom track 3 seconds

Vegas Pro 12
Both Tracks 12 seconds
Delete Event on bottom track 5 seconds

Vegas Pro 13
Both Tracks 12 seconds
Delete Event on bottom track 5 seconds

I've been aware of this for quite a while and always assumed it was because Vegas doesn't really have a setting for a compositing mode that doesn't "composite."

If there was a way to simply set a track to "replace lower video track," or something of that sort, I would consider this behavior a bug. But since the default mode is "source alpha," doesn't Vegas have to composite lower tracks on every frame "in case" alpha is present on the higher track?

@atom12

Good question. But what if the lower track is muted? In a multicam track, only the active take is "active" and the rest is actually muted for the duration.

That is a good point. I don't use multicam much so that escaped me. In that case it would be a bug - or sloppy coding at the very least. Perhaps the order in which properties are checked by the software? Maybe resizing or pan/crop takes place before the mute setting is checked?

Funny you should bring this up John M.. Just the other day I noticed that my VP13 project was playing slower on the timeline when I had a completely obscured lower track on, and faster when it was muted. I thought "That's not right!". Maybe I'd just not noticed it before, but I always had the feeling that Vegas is intelligent enough to know when to ignore lower tracks.

Anyway, here are my test results:

Vegas Pro 10
Both Tracks 6 seconds
Delete Event on bottom track 2 seconds

Vegas Pro 12
Both Tracks 4 seconds
Delete Event on bottom track 1 second

Vegas Pro 13
Both Tracks 4 seconds
Delete Event on bottom track 1 second

OldSmoke, turn you GPU off!

Interesting. I see that johnmeyer's screenshot shows no muted tracks. Has anyone tested if muting the tracks has a different result than deleting them?

I just did your render bug test, both tracks. It finished in 2 seconds.
Delete bottom track. Render finished in 1 second.

Yes, I tested muting track vs. deleting event. Both have exactly same impact on rendering here.

As mentioned in my post above even different event fx of the lower event (which should not affect processing at all) does affect the render time.

[I]OldSmoke, turn you GPU off![/I]

Now that would be counter productive, wouldn't it? :-)

[I]Yes, I tested muting track vs. deleting event. Both have exactly same impact on rendering here.[/I]
That would mean it doesn't really matter then in a multicam project since the portions where it is muted get's render fast?

@marco, And that would make sense if checking for alpha on the top layer is the last step in the compositing process. It seems it would have to process all lower tracks first, fx included.

"And that would make sense if checking for alpha on the top layer is the last step in the compositing process."

Yes, in a certain way it does. What brings me back to what videoITguy mentioned in his post. Though this is unexpected behaviour for us at a first glance must not be a bug necessarily. It could be due to the compositing design indeed and it would be very interesting to investigate how other compositing systems (After Effects, HitFilm, others) process same project structures.

"That would mean it doesn't really matter then in a multicam project since the portions where it is muted get's render fast?"

I think you're right here, though I didn't test a regular multicam project – just the given test project.

After Effects (at least CS5) reacts somewhat similarly, although it appears much more intelligent in the way it caches material.

I set up a 1080i composition and imported 5 different uncompressed avi's and layered them on the timeline (none have alpha). Set render length to 30 frames. Duplicated that composition twice. In comp 1 I muted all tracks except the top. In Comp 2 left all tracks unmuted. In comp 3 I left all tracks unmuted, but applied a luma key to the middle (third) layer.

Put comps 1,2,3 in the render queue and started. Comp 1 rendered in 2 seconds. Comp 2 rendered in 8 seconds. Interestingly, Comp 3 rendered in 2 seconds. So it seems that some information from Comp 2 had been cached and AE remembered that there was no need to render the layer with the luma key applied. Just my guess, but the initial renders of Comps 1 and 2 point to it handling compositing layers similar to Vegas.

"Just my guess, but the initial renders of Comps 1 and 2 point to it handling compositing layers similar to Vegas."

Indeed. Interesting test.

John, I haven't downloaded your example, but since Vegas9c was already open on my desktop, I tried a couple of quickie tests:

(1) Very short HDV clip, render to MPEG2 in :27

(2) Add second HDV clip underneath, renders in :28

(3) Add Gaussian blur to second clip, renders in :28

(4) Add third HDV clip underneath, add Gaussian blur, renders in :28

(5) Split top clip just 1 frame wide so it has to render 1 frame of second HDV clip with Gaussian blur, renders in :28

(6) Add fourth video clip underneath, this time an MJPEG clip, renders in :28


Now admittedly I'm not doing anything sophisticated here, but isn't Vegas behaving properly in this instance? Nothing fancy, just stacking multiple clips on the timeline and Vegas ignores everything underneath as expected. No clip has any dependencies on any other.

riredale

Try a pan/crop and zoom out of the picture so that it leaves a black bar all around, then try rendering again as this will introduce an alpha channel or at least processing it.

Just had a chance to get on the computer with Vegas and found some interesting things. Tested in Vegas 9e and Vegas 11:

1. With 5 1080 clips stacked in a 1080 project, a five second selection render took 6 seconds, no matter which lower clips were muted/unmuted, had effects applied, or were rotated in pan/crop.
2. Inserting a single 720 clip on the lowest track increased rendering time to 12 seconds - even though it was completely covered by other clips.

Is the issue simply with adjusting non-conforming clips to the project size, even if they are not being composited?

Many thanks to everyone for responding so quickly, but especially to Marco and BruceUSA for testing, and even more to both john_dennis and Nick Hope, both of whom tested multiple versions and confirmed that this is still a bug, even in Vegas 13.

And yes, I am quite certain that it is a bug, and not the way compositing should work in this, or any other NLE. I say this because the Vegas 5 compositing bug that I found (see my first post for a link to the ancient thread) was acknowledged by SCS and eventually fixed. It was very, very similar to this one.

There is no way that media on lower tracks should affect rendering time if that media is not being used. To test whether anything was "showing through" from the lower track, I temporarily adjusted the color corrector fX that was already on the lower event so that it bleached all the video. I then muted & un-muted this lower track while looking at the display (which was set to Best-Full). If any video from the lower track was being used in any way, I should have seen some change as I muted and un-muted the super-bright video on the lower track.

I saw no change whatsoever.

BTW, in answer to a couple of questions, the "match media" option in project properties is un-checked. It is evil and should never be used, IMHO.

As I said in the first paragraph of my initial post, this is not some obscure problem but instead is something that affects almost everyone who has ever used this product. What's more, it may explain a few of the posts where people have complained about super-long render times. Yes, many of those posts are also due to people not understanding how long things take, or because they don't have sufficiently fast computers, or because they are making mistakes, but many of them have never been explained.

I will be reporting this to SCS as a bug.

In the meantime, I am considering writing some sort of script that will remove media from lower tracks. This may not be useful because, of course, in many projects the media on the lower tracks IS being composited and therefore should not be removed. I don't know if there is a way to programmatically determine if compositing is taking place. It took about fifteen minutes last night to remove all the events on the lower channel that were "underneath" the events on the upper channel. It involved a lot of cutting and then removing, followed by a very thorough check at all the boundaries and dissolve points to make sure I hadn't screwed up anything. Doing this cut my render time from a projected 18 hours to an actual 9 hours. Not bad for fifteen minutes work.

And, oh yes, one more big thanks to Nick Hope for his wonderful work on producing the best possible DVD from HD material. I once again did a comparison, just to make sure the work we did back then really matters. I created fifteen second clips and put them on a DVD using Vegas MPEG-2 encoding as the starter, but then using AVISynth to do the downsizing, first using QTGMC and then TDint. I viewed the results on the big screen, and the two workflows that Nick created produced much sharper, better results.

Great stuff!