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.

Back to post

Comments

OldSmoke wrote on 12/24/2014, 11:15 AM

[I]That is the spirit I was brought up with[/I]

While that is a good spirit and mine too, it breaks apart the moment finance has a say in what is going with a product.

If you want faster render, get a better hardware especially if you are making money and a living from it. If not, time shouldn't play such a big role.

johnmeyer wrote on 12/24/2014, 12:04 PM

If you want faster render, get a better hardware especially if you are making money and a living from it. If not, time shouldn't play such a big role. That completely misses the point, and is a total non sequitur (i.e., it does not logically follow ...). Yes, a faster computer will make things go faster, but once you get the fastest computer in the world, then what? Your render simply cannot get any faster, and since the rate at which computers are getting faster has slowed dramatically in the past decade (no more "Moore's law;" just massive parallelism, which doesn't translate to performance for many tasks), you are going to be stuck with whatever performance you get from your new computer for many years to come.

But wait, your Vegas renders and preview performance CAN still get faster, because it is both the computer AND the software which determines performance and, as I have demonstrated in this thread and as others have confirmed, there is a HUGE amount of performance improvement possible for many projects, just by addressing this "issue" (since some don't like to call it a bug).

Why are people resisting? Is a nine hour render really fast enough for you? I am talking here about a guaranteed performance improvement that, depending on the nature of your project, could be far greater than any performance improvement ever offered in any new release of Vegas, including the introduction of GPU support. Yes, it will not improve performance on all projects, but for those that it does (like mine, or like most multi-cam projects), the improvement will be massive.

And yet, people here are arguing against it. Wow.

OldSmoke wrote on 12/24/2014, 1:02 PM

Ok, so I want to be a good sport and did some testing with footage that puts some strain on my system. I used several files of 4K XAVC-S footage from my AX100 spread over three tracks, cut to make out exactly 1min. and applied to Pan/Crop to the lower two tracks.

The Pan/Crop was applied so that it would leave a small frame of alpha channel around the image.
I rendered it to 1280x720@60p, which is completely off from the original footage, and I got:

33sec. with all tracks on
33sec. with the lower two track muted
33sec. with just one track only (I deleted the lower two tracks)
45sec. when I make a multicam track of the three video tracks with multiple 15frames cross cuts.
42sec. for the multicam track when I converted the cross cuts to straight cuts.

So, on my system, there is absolutely no difference between I track or many tracks.

Why I am resisting? I prefer Sony to focus on the real bugs, the ones that affect all of us and not introduce a potential problem by trying to convert the "brute force but works" rule in this case.

Edit:
I did a second test with different footage:
Track 1: 4K 30p from AX100
Track 2: 1080 60p from HF G30
Track 3: HDV 720 60p from HXR-NX5U

Result: 25sec. no matter whether there is a Pan/Crop, 1 track or three tracks it is always the same render time.

farss wrote on 12/24/2014, 1:12 PM

[I]"Why are people resisting?"[/I]

1) Brute force might be faster. You ignored that aspect. Given that Vegas is a full blown compositing application the code that you want SCS to write may make what you're trying to do faster but make what others want to do slower.

2) Your issue is already solved. SCS long ago provided us with the solution to this issue, use Vegas's Multicam Editing feature and your issue with how it does compositing goes away.

Bob.

videoITguy wrote on 12/24/2014, 1:16 PM

johnmeyer, You make very valid points throughout this thread. Your experience as a software engineer is invaluable, as is mine, and many others who have chimed in from that special perspective. I thank you for creating this thread - it does prompt investigation - but actually more relevant for VegasPro against other compositing apps rather than against itself.

The point is well made that there are many huge bugs existing in VegasPro and they should be corrected - but the summary of this thread would appear to be that this issue would not be a worthy option to prioritize. You may feel to the contrary, and I respect that, but look at the preponderance of real -world users experience...

Former user wrote on 12/24/2014, 1:18 PM

Bob beat me to it. I was about to say, "But that's what multicam editing is for..."

Merry Christmas all...

johnmeyer wrote on 12/24/2014, 1:58 PM

I give up.

larry-peter wrote on 12/24/2014, 2:18 PM

I am totally with marco's earlier suggestion of a "none" compositing mode that ignores all clips beneath universally. It doesn't seem that this option would introduce anything that compromises time in AI checking of properties when compositing is required.

OldSmoke wrote on 12/24/2014, 2:34 PM

I don't know what else to do. As my test above shows, there is absolutely no difference no matter what I did; unless I missed something.

farss wrote on 12/24/2014, 2:46 PM

[I]"I am totally with marco's earlier suggestion of a "none" compositing mode that ignores all clips beneath universally. It doesn't seem that this option would introduce anything that compromises time in AI checking of properties when compositing is required. "[/I]

What do you want to happen when there's a fade?
What do you want to happen with unquantized frames?

What might make more sense would be a global "Early Avid Mode" switch. :)

Bob.

Warper wrote on 12/25/2014, 8:26 AM

Fade will produce fade with zero transparency. That is, black color at the end, no transparency.
Unquantized frames are lost. AFAIK they are lost anyway, but sometimes produce crashes, so losing them will not make things worse. There are other means to deal with unquantized frames.

farss wrote on 12/25/2014, 6:40 PM

I ran some more tests, I was planning on plotting the results but as shown below, that would seem rather futile:



    # Tracks          Render Time

                      in seconds

         1                 29

         2                 29

         4                 28

         8                 28

        16                 28

        32                 29

As before this was using EX1 footage, 25p MP4 rewrapped to MXF
and rendered to the same codec. All renders ran with "No recompression".
No FXs, no pan/crop, nothing but vanilla FullHD. Project and video on each track was 60 seconds long and each track contained different video.

This is different to what I got before, why?
This time I removed the audio tracks. Vegas will always have to at the very least to mix all the audio tracks and that does take CPU cycles and the more tracks of audio the more CPU cycles.

I wonder if this to some extent explains the variation in what posters above have reported?

Bob.

Jedman wrote on 12/25/2014, 7:47 PM

Just to complicate things further, but may be related-

I found this a few months ago, most of what I do is multicam, and about half the time for various reasons I nest the cams in their own projects and pull the vegs in to a new project to form the multi cam track.

With one 4k nested cam in a 5 cam multi the playback is woeful, so I use a proxy 1080p version of the 4k in its project,
-render to a new track and mute the 4k track underneath. Sfap file gets rebuilt in the multi cam project and preview is back to Best full in the multicam project.... or so it should be. But its not. 5fps :(

So, suspecting some funny business, go back into nested 4k project and delete the muted 4k track....
Sfap file gets rebuilt in master project ( I wonder why, since it was muted and should not be affecting the playback of the 1080p track above)..... and it still previews at 5 frames a sec. Not happy.

Go back to nested 4k and go Tools- Clean Project Media.
So now all that is in that Project is the 1080p proxy.

Finally, playback is back to Best Full in the multicam project.

So, why is Vegas looking at unused footage in the media bin when processing a Nested Veg file?

OldSmoke wrote on 12/25/2014, 8:36 PM

Could it be that the project settings in your nested project where still set at 4K even tough you where not using the file?

Jedman wrote on 12/26/2014, 4:11 AM

No, project settings for editing are always 1080p 8bit through all nests and same in the multi project.
It was very weird

Marco. wrote on 12/26/2014, 5:22 AM

"I wonder if this to some extent explains the variation in what posters above have reported?"

In my case: No. I used the test project John linked in the first post and there is no audio in the timeline.

To me it rather looks like in case of smart rendering things change. So why not trying some video which does not smart render?

farss wrote on 12/26/2014, 6:40 AM

[I]" So why not trying some video which does not smart render?"[/I]

So we are comparing apples to apples I used the same projects but rendered to PAL DV WS:



                               Unstretched                  Stretched

# tracks                        PAL DV WS                   PAL DV WS

 1                                 27                          42

 2                                 58                          26

 4                                 72                          27

 8                                125                          27

16                                804                          27

Now that WAS interesting.
It seems that not having video that is simplistically seen as filling the frame causes Vegas to decode and composite every track. I suspect the huge blowout at 16 tracks of unstretched PAL DV WS was due to Vegas running out of RAM to buffer all the GOPs worth of frames from 16 tracks.

Bob.

OldSmoke wrote on 12/26/2014, 8:25 AM

@Bob

Maybe your result is what John was seeing too. If he doesn't have stretch to fill ticked then every layer has a small bar on the sides and hence Vegas will tread it as alpha, trying to composite the underlying layer. I don't see that when I render to NTSC DVD because I use 704x480 which doesn't require stretch to fill and Inalso have it always ticked anyways.

farss wrote on 12/26/2014, 2:48 PM

[I]" Maybe your result is what John was seeing too. If he doesn't have stretch to fill ticked then every layer has a small bar on the sides and hence Vegas will tread it as alpha, trying to composite the underlying layer."[/I]

Possibly so.
The sudden blowout between 8 tracks and 16 tracks is also interesting, going from 125 to 804 seconds! All the cores were running at around 80% and over 5GB of the 8GB of RAM were being used.

Bob,

rmack350 wrote on 12/27/2014, 1:32 PM

Just some observations. I'm sitting in a hospital and writing on my tablet so I can't test anything.

Bob made a kind of telling comment when he talked about testing on a pixel by pixel basis. Obviously that'd incur a bigger cpu cost than testing frame by frame or event by event. I assume Vegas tests on a frame by frame basis but it could read the events and set a variable.

Once you have the event flagged as compositing=true then vegas has to compute the events below and do the composting math. Sometimes the end result is no change but you still have to do the computation to find out.

I think it was hit on that getting events unto the same track helped and was easier to visualize in a more traditional A/B view.

I wonder what happens if the underlying events are just generated solid colors. Can you add fix to make thme impact render times? Just looking for a way to simplify the problem.

Rob

Grazie wrote on 12/27/2014, 1:49 PM

Rob - hospital? More important. I wish you well.

Graham

larry-peter wrote on 12/27/2014, 2:44 PM

I'll leave it to others to interpret, but my tests point to something more than simply seeing alpha, or "black" around lower tracks. I can confirm Bob's results when rendering to a different screen aspect ratio with "stretch to fill" NOT checked. Here's what I got today:

Project settings - 8 bit, 1080p 23.976fps
From highest track down, first 4 tracks are 1080p 23.976 AVCHD
5th track is 720p 23.976
6th track is HDV 1440 23.976
rendering selection 10 sec

Rendering to .mxf HD-EX 1920X1080 - 24p
track 1 only - 10sec
1 & 2 - 10 sec
1,2,3 - 10 sec
1,2,3,4 - 10 sec
1,2,3,4,5 - 10 sec
1,2,3,4,5,6 - 10 sec

Rendering to .mxf HD-EX 1920X1080 - 24p with all tracks other than track 1 rotated or pan/cropped to expose black around edges:

Same results as above

Rendering to .mxf DV 24p widescreen
1 track - 14 sec
1,2 through 1,2,3,4,5,6 - 14 sec No difference

Rendering to .mxf DV 24p widescreen with all tracks other than track 1 rotated or pan/cropped to expose black around edges:

Same results as above

Rendering to .mxf DV 24p (stretch to fill NOT checked)
1 only - 12 sec
1,2 - 16 sec
1,2,3 - 13 sec
1,2,3,4 - 16 sec
1,2,3,4,5 - 40 sec
1,2,3,4,5,6 - 1:05
(checked twice and the 13 second anomaly with three tracks is consistent)

Identical results in DV 24p with lower tracks rotated/cropped.

Edit: To be clear, this was done in Vegas 11 with all audio tracks removed.

larry-peter wrote on 12/27/2014, 4:10 PM

I had posted the above test and realized that I couldn't reproduce the results of my first test (WAY up in this thread) where as soon as I added a clip of a different size (a 720 clip beneath a 1080 clip in a 1080 project) that rendering time increased. I went back to see what format I had rendered to (I didn't even check at the time) and it was a 720 X 480 NTSC mp4.

Looking quickly through the tests by others in this thread (including johnmeyer's) it seems that this "covered-up-track" compositing is only taking place when altering pixel aspect ratio from project settings to render settings. Have I missed a test where this WASN't the case?

rmack350 wrote on 12/28/2014, 10:58 AM

Grazie, Aging parent, not me. We're managing. I'm learning the names of everyone on my mother's floor. Hospital has WiFi, which is great as I can read while I watch her sleep. Also starting to see a use for phone and tablet video cameras as I can bring her other people's good wishes.

As for Vegas having a bug or a design bottleneck, the question to me is weather this should be addressed as logic or as design. A design approach would lead you away from troubles and give you easy ways to pinpoint and fix the trouble you created. A logic or programming approach would attempt to male the software foolproof, which we all know is impossible because we fools are so ingenious.

Rob

1 2 3 4 … 5

of 5