Possible explanation for some slow renders .. bug?

johnmeyer wrote on 12/23/2014, 3:05 AM
I've found what may be a bug that can lead to horrendously long renders. If it really is a bug, it has probably affected almost everyone reading this post.

I'm rendering my annual two-camera Nutcracker shoot, and couldn't figure out why the render slowed down after the first three minutes of the project. I found the answer, and think it is a Vegas bug. I need someone to test my results. I've only tested on V10, but I suspect this problem exists in later versions. Here is a link to a 50 MB zip file that contains the V10 VEG, plus two small video files:

Render Bug Test

Here's a brief description of what causes the problem. I have HDV on the top track and HD (1920x1080) interlaced on the bottom track. In my two camera shoot, I cut between them, but don't bother to remove the HD when it is covered by the HDV. Someone bumped my HD camera, and it is slightly out of line, so I uses pan/crop to rotate it. Thus, in this screenshot, the top track contains HDV video, and the bottom track contains HD video, slightly rotated:



When the render gets to the HD portions (where there is a gap in the video in the top track), it slows down. This is what I would expect.

However ...

When the project renders the HDV on the top track, it goes just as slow as the HD. But, if I remove the "unused" HD event from that is under the HDV, guess what? The render of that portion of the project speeds up, and speeds up by a LOT.

Thus, Vegas appears to be using the video on the bottom track, even though it is obscured. This seems like a bug, and a major one at that. This has happened before. Many, many years ago, in Vegas 5, I saw a similar behavior when Vegas would slow down the whole project when any compositing was done anywhere on the timeline, even if it was only done for a few frames.

Compositing causes ENTIRE project to render?

Testing the bug will take less time than it takes to download the file. To do the test, unzip the files to a folder, open the VEG project file and render it to NTSC DVD Architect Widescreen MPEG-2. Write down the time it takes to render. Then, delete the event from the second track and repeat the render.

I just did this test (I was doing a large render in the background, so the absolute times are long) and with the HD event on the bottom track, the render took 22 seconds. Once I removed it, the render took 6 seconds. Almost 4:1 !!!

If this is a bug, it is not minor.

Comments

videoITguy wrote on 12/23/2014, 3:18 AM
I don't think it is a bug as much as it is a by-product of design. Keep in mind how Vegas works with track layering to achieve compositing and what that coding entails.

What you need to do for your own edification is not test Vegas again - because all results should essentially be the same. Instead investigate how compositing is done in another NLE and see what results that produces with the same project sources and output parameters.
farss wrote on 12/23/2014, 3:53 AM
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.
Grazie wrote on 12/23/2014, 4:13 AM
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


Marco. wrote on 12/23/2014, 4:59 AM
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.
OldSmoke wrote on 12/23/2014, 9:03 AM
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.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: Intel DX79SR
Ram: G.Skill 8x4GB DDR3 2133 (running at 1600 and lower latency)
CPU: 3930K @ 4.3GHz (custom water cooling system)
GPU: 1x ASUS Fury-X
Hard drives: 4x 2GB WD Red in RAID 5 (with Hot Spare), 2x Crucial 256GB SSD in RAID 0 (mulitcam project drive), 1x Samsung 850 Pro 256GB SSD (System), 1x Crucial 64GB SSD (temp files and swap file), 1x 3.5" Hotswap Bay, 1x LG BluRay Burner
PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM, 1x Sony HDTV 32" preview monitor

john_dennis wrote on 12/23/2014, 9:04 AM
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
larry-peter wrote on 12/23/2014, 9:26 AM
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?
OldSmoke wrote on 12/23/2014, 9:58 AM
@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.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: Intel DX79SR
Ram: G.Skill 8x4GB DDR3 2133 (running at 1600 and lower latency)
CPU: 3930K @ 4.3GHz (custom water cooling system)
GPU: 1x ASUS Fury-X
Hard drives: 4x 2GB WD Red in RAID 5 (with Hot Spare), 2x Crucial 256GB SSD in RAID 0 (mulitcam project drive), 1x Samsung 850 Pro 256GB SSD (System), 1x Crucial 64GB SSD (temp files and swap file), 1x 3.5" Hotswap Bay, 1x LG BluRay Burner
PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM, 1x Sony HDTV 32" preview monitor

larry-peter wrote on 12/23/2014, 10:14 AM
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?
Nick Hope wrote on 12/23/2014, 10:25 AM
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!
larry-peter wrote on 12/23/2014, 10:41 AM
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?
BruceUSA wrote on 12/23/2014, 10:56 AM
I just did your render bug test, both tracks. It finished in 2 seconds.
Delete bottom track. Render finished in 1 second.
Marco. wrote on 12/23/2014, 11:15 AM
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.
OldSmoke wrote on 12/23/2014, 11:26 AM
[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?

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: Intel DX79SR
Ram: G.Skill 8x4GB DDR3 2133 (running at 1600 and lower latency)
CPU: 3930K @ 4.3GHz (custom water cooling system)
GPU: 1x ASUS Fury-X
Hard drives: 4x 2GB WD Red in RAID 5 (with Hot Spare), 2x Crucial 256GB SSD in RAID 0 (mulitcam project drive), 1x Samsung 850 Pro 256GB SSD (System), 1x Crucial 64GB SSD (temp files and swap file), 1x 3.5" Hotswap Bay, 1x LG BluRay Burner
PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM, 1x Sony HDTV 32" preview monitor

larry-peter wrote on 12/23/2014, 11:27 AM
@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.
Marco. wrote on 12/23/2014, 11:48 AM
"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.
Marco. wrote on 12/23/2014, 11:51 AM
"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.
larry-peter wrote on 12/23/2014, 12:52 PM
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.
Marco. wrote on 12/23/2014, 1:03 PM
"Just my guess, but the initial renders of Comps 1 and 2 point to it handling compositing layers similar to Vegas."

Indeed. Interesting test.
riredale wrote on 12/23/2014, 1:22 PM
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.
OldSmoke wrote on 12/23/2014, 1:35 PM
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.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: Intel DX79SR
Ram: G.Skill 8x4GB DDR3 2133 (running at 1600 and lower latency)
CPU: 3930K @ 4.3GHz (custom water cooling system)
GPU: 1x ASUS Fury-X
Hard drives: 4x 2GB WD Red in RAID 5 (with Hot Spare), 2x Crucial 256GB SSD in RAID 0 (mulitcam project drive), 1x Samsung 850 Pro 256GB SSD (System), 1x Crucial 64GB SSD (temp files and swap file), 1x 3.5" Hotswap Bay, 1x LG BluRay Burner
PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM, 1x Sony HDTV 32" preview monitor

larry-peter wrote on 12/23/2014, 1:52 PM
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?
johnmeyer wrote on 12/23/2014, 2:49 PM
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!
altarvic wrote on 12/23/2014, 3:23 PM
> "I don't know if there is a way to programmatically determine if compositing is taking place."

This is not a trivial task (eg. title with transparent background on the top track). You can create regions and delete everything within these regions on the selected tracks.
Vegasaur users can do it with Markers tool ;)