John, agree this is a bug and thanks for pointing it out. Do you see the same behavior in projects where all source material matches project settings?

I ask because in my post directly above yours, I couldn't get the same results as you until I added a clip that didn't match project properties. Then Vegas seemed to require processing a hidden lower clip during render. Just wondering if this would help point to a solution.

Just ran my own tests using 1080p FullHD.

1:00:00 Project

1 Track of media: 0:30 to render to MXF

12 Tracks of media: 1:20 to render to MXF

In both cases the video was flagged as "No recompression required"

Also:

I can full fps playback at Best/Full with 1 track of video or 12 tracks of video and 12 tracks of audio.

What does seem to happen is V13 is slower to actually start playing back with more tracks of media.

Bob.

Do you see the same behavior in projects where all source material matches project settings? That is a very interesting question. Let me test that ...

While I'm testing, for those who didn't pick up on it in my long first post, the video on the top track is 1440x1080 NTSC HDV, but the bottom track is 1920x1080 60i video. The project properties are set to match the top track HDV material because that is the main camera that is zomming, etc., whereas the other camera is mounted directly next to it (I run them both) and just sits there are films the entire stage. It is my cutaway/cover shot camera. So, by matching the properties to the top track, I get the smoothest, fastest playback of that camera.

OK, test result, using my test project, are finished. The renders are faster because I'm not doing any background renders.

Original project: 13 seconds (to NTSC Widescreen MPEG-2)
Remove video event from bottom track: 4 seconds
Replace bottom track video event with duplicate of top track, but rotate, using pan/crop: 11 seconds

So, it doesn't matter if the video is the same as the video on the top track, and if both match the project properties; the problem still happens. The slight reduction in rendering time (11 vs. 13 seconds) in my last test is explained by the fact that there are fewer pixels to process when using HDV.

[I]" So, it doesn't matter if the video is the same as the video on the top track, and if both match the project properties; the problem still happens"[/I]

See my results above, I am NOT seeing this.

Bob.

I did not see that result either, but I only have 9e and 11 on the machine I was testing with. Rotating lower track clips made no difference in render time if they matched project settings - BUT adding one clip of a different size to a lower track DID increase render time. GPU was off, as always on my machines.

Edit: Could this have something to do with non-square pixels?

I used V12. (I may try V8 later but have to eat). I suspected what you saw was some buffering type of thing, so I closed out of V12 then reopened between each timing. Technically, I should probably reboot before and between but didn't.

First run = 10sec
Second run = ~2sec

So about your 4:1 ratio.

So that may explain that 40hr render in V8 several years ago.

I've always suspected something like this.

Have you set the project properties to the higher 1920x1080 and measured? The project opened with HDV for me. I suspect it slows down to resize the higher resolution file?

[I]" Edit: Could this have something to do with non-square pixels?"[/I]

That was one of my suspicions from the outset.

It seems to me that there's a certain amount of jumping to conclusions going on here. If I had the time what I'd do is run the test for 1,2,4,8,16 tracks of vanilla FullHD and plot the results .

Bob.

I reset the project to 1920x1080 and still got 10sec with both tracks, so it's not project properties

Bob,

I am not quite sure how to interpret the results of your test. In a later post you say you didn't see any problem, but I thought your tests were showing an increase in render time, merely by placing more tracks below the main track. I presume (similar to "assume") that the project was configured so that none of the lower tracks were contributing to the final video.

I haven't yet tested using full HD (i.e., square pixel) for both tracks. I'll do that in a few minutes.

BTW, one thing some many have missed in my overly-long initial post (what else is new?) is that the video on the bottom track has a pan/crop rotation applied. I need to do more testing to see if that is required to make this problem happen.

It still seems as though most people who have downloaded the project/media have been able to duplicated the problem on all versions of Vegas.

"Could this have something to do with non-square pixels?" .... That was one of my suspicions from the outset.Well, I just did another test, and this really drives home that this is a bug.

This is the simplest possible set of tests.

Test #1: Create a new project with just one track and drop the 1920x1080 60i AVCHD clip onto that track. Add a color corrector fX to that event, and change any setting in the dialog in order to make sure no smart rendering happens. Render this using the MPEG-2 NTSC DVD Architect Widescreen codec/template and record the time.

Test #2: Copy/paste the event to the track below and repeat the render.

I just did this, and the second render was

So, in this much simpler test, I used the identical media on both tracks, and I did not apply any pan/crop which, I suppose, might have fooled Vegas into thinking there were some pixels at the margins from the event on the bottom track that needed to be taken into account.

Finally, just for grins, I copied the event onto three more tracks, for a total of five tracks, all with the identical 1920x1080 60i AVCHD video clip (from a Sony CX-700 camcorder). This render was almost exactly 5x longer than the original.

I did all of these latest tests in Vegas 13.0, Build 373.

Thus, for those of you who create projects with many tracks of video, and where video on lower tracks sometimes is not being used, this bug could be absolutely deadly. I was only doing a two camera shoot, but imagine doing a five-camera project!! In most multi-cam edits, you simply cut between cameras, with perhaps a few transitions thrown in for good measure. Video is usually only being taken from one track at a time. Therefore, with this bug, the render times will be three to five times longer than they need to be.

If Sony doesn't acknowledge this or fix it, then hopefully we can interest some of the third-party programmers to come up with a script fix that will either temporarily or permanently remove media prior to a render. Such a script would be somewhat similar to what is done for proxies. In that case media is replaced; in this case it would be removed. The scripting interface provides access to many of the settings which determine whether video on lower tracks is going to affect the final video. A script will need to know all of this information in order to determine whether it is OK to remove media on lower tracks. I don't know if all these settings are available via the script API.


I am slowly coming to grips with how much of my time (and my life) has been wasted over the past few years because of this. It actually makes me feel a little sick.

[I]"I am not quite sure how to interpret the results of your test. In a later post you say you didn't see any problem, but I thought your tests were showing an increase in render time, merely by placing more tracks below the main track. I presume (similar to "assume") that the project was configured so that none of the lower tracks were contributing to the final video."[/I]

Sure, it increased but not dramatically, especially considering I had 12 tracks of video. Also Vegas was Smart Rendering the footage. If it was trying to actually composite those 12 tracks it couldn't have smart rendered the footage.

I suspect what's going on here is a reasonable level of smarts are being used which does still add some overhead as we add more tracks. At the same time the code has a lot to check before it can decide it can ignore anything on the tracks below. If we had a bug where Vegas failed to composite something that it should have there'd be blood on the walls. By comparison it not being quite as smart as we'd like it to be, I think we can live with that.

I've never used Vegas's Multicam feature but if that's used doesn't it collapse all tracks down to one anyway?

Bob.

I think calling this a "bug" is a little too strong. There's certainly room for optimization in this case, but Vegas is doing its job as a compositor.

When there are multiple layers in the composition, Vegas is rendering the lowest image to the canvas, then rendering the next higher image and combining it onto the canvas according to the compositing mode for that layer, and repeating for the next higher layer, etc., until it finishes with the uppermost layer.

Surely this process could be optimized, however, by first looking from the top layer down and locating the first layer that (1) contains source media that does not support alpha, (2) which is still set for 100% opacity, and (3) which fills the output canvas. All layers below are obscured and would not need to be rendered or composited.

The analysis needs to be much more detailed than that, though, as Video FX can create alpha situations even if the original media (HDV, DV, AVCHD) doesn't support an alpha channel. (For example, HDV media with Chroma Keyer, or Cookie Cutter, or any other similar FX.) It's easy for us to just "know" that the lower layers are obscured and don't need to be rendered, but it's tricky for a program to know that.

Obviously, this optimization check would need to be made independently on each frame, as crossfades and transitions can change some frames to < 100% opacity even when the original media has no alpha channel and has no FX applied.

@John Meyer: I wonder how the render time would be affected if you selected all of the events on your top track and used the number pad down arrow key to move them to the lower track -- on top of the continuous wide shot -- then deleted the top track. In this case, I think Vegas would only be rendering a single layer for each frame, and the render would probably be faster. (But I don't know what would happen doing this with mixed media. And I don't know if this is acceptable practice anyway.)

Okay, I went back and ran a few more quickie tests. I'm working with 9c and HDV.

As long as the top track was at 100% Level, Vegas ignored everything below, no matter what I did to the lower tracks.

BUT as soon as I put a pan/crop keyframe on that top track, Vegas would "render" out the lower tracks, even though they were invisible in the final result. Two tracks=2x the render time.

Go back to the top track, erase the pan/crop keyframes, and Vegas renders normally again.


EDIT: Wait a sec. Of course. It HAS to render out everything below--Telling Vegas to pan/crop means telling it to move the top image around. So it needs to render out whatever's underneath also in order to deliver the result the editor wants.

Or maybe I'm missing the whole point of this thread.

I wonder how the render time would be affected if you selected all of the events on your top track and used the number pad down arrow key to move them to the lower track -- on top of the continuous wide shot -- then deleted the top track.Well aren't you the clever one! That is a very nifty workaround. It works perfectly, and takes my fifteen minutes of work, and reduces it down to five seconds.

I tested, and everything rendered lickity split (technical term) after I put everything on one track.

For others who want to try this, there is one thing you have to pay attention to, and that is to figure out which event is going to end up on top. I initially tried dragging the event from the top to the bottom track, but it ended up underneath the event on the bottom track. Obviously, I want it on top. The Num Pad shortcut that Tim suggested does the same thing. However, a simple cut/paste provides the desired result, with the event(s) from the top track on top of the event(s) on the bottom.

As for whether this is a bug, so far those who don't think it should be called a bug simply say that it is complicated to determine whether the video on lower tracks can be ignored, and therefore if all this wasted CPU time can be reclaimed. While it is true that it would take a little thinking on the part of the programmer assigned to fix this problem, it is far from impossible. Heck, this is what programming is all about. You simply figure out all the settings which control whether video from lower tracks will show through (fX settings, track composite settings, parent/child relationships, relative video size and shape, track motion, pan/crop, etc.). When none of them have been set, you tell the rendering (or preview) logic to ignore video on the lower tracks.

BTW, speaking of preview logic, I just tested, and if you create enough duplicate tracks, all with the identical event(s), one above the other, the preview speed slows down. With 18 tracks, I went from full frame rate at Best/Full with two fX applied to one frame every five seconds!! So, the same issue happens with preview.

Sony (SCS), this is something you can fix, whether you want to call it a bug or not. You can create a logic table of all the settings you need to check, and then create a "dirty flag," or something similar which gets set when any setting in that table has been altered to a state which would require compositing. You do this for each frame. When you discover that even one setting is set which would cause video from that track to be used in the final result, you can bail from the check and then go ahead and use that video in the render or preview calculations. Such a check should take a small fraction of the time actually needed to perform the compositing operation.

Putting a media item on top of another event (on the same track) is something -- as an amateur hobbyist -- I've done accidentally numerous times. However, I'm not 100% sure what "rules" it follows in determining which event to show. And I'm not sure if this is a proper thing to do, or if it is ill advised. So I normally wouldn't do it. (Because I'm chicken...)

Right-click on the track header and enable "Expand Track Layers" for a nice graphical representation of what Vegas plans to render. Note that you can still do crossfades or transitions in the expanded track view.

I think whichever event is first on the track becomes the "A" event, and the other one becomes the "B" event. It seems to automatically switch to the opposite event each time a new leading edge is encountered. It automatically switches back each time an event ends.

If you have one event that is continuous and uninterrupted, this might work well. However if both events have breaks or splits -- better watch closely to see that it does what you are hoping for... (Please, folks, don't come down on me if this doesn't work right! :)

I never paid any attention to "Expand Track Layers." The help file isn't very useful on this subject. I need to play around with it to understand what it is intended for. It certainly helps provide additional insight when using your suggested workaround. Thanks!

[I]" As for whether this is a bug, so far those who don't think it should be called a bug simply say that it is complicated to determine whether the video on lower tracks can be ignored, and therefore if all this wasted CPU time can be reclaimed. While it is true that it would take a little thinking on the part of the programmer assigned to fix this problem, it is far from impossible."[/I]

That holds true for what we're discussing here however Vegas is also a full blown compositing application.
What's on track 1 can have an alpha channel, it can have one of many compositing mode, masks, track and event pan/crop. Having decided that for a given pixel that's on track one it needs data from track 2 then it has to go through the same process again. Rinse an repeat for an unlimited number of tracks.

Having determined what needs to be calculated then the actual compositing calculations need to be done and they have to be done from the bottom track up.

In the end it caould well be than more CPU cycles could be used working out what doesn't have to be done than simply taking a less finessed approach and doing it all anyway. Sometime "brute force" is easier to maintain and a faster way to code something.

Bob.

farss +1

Then – would an additional compositing mode "None" help (actually kind of "none compositing mode")?

Sometime "brute force" is easier to maintain and a faster way to code something.For version 1, yes. For version 13, no way.

This is especially true when you consider what we're talking about. How much would you pay for a new Vegas feature that would cut rendering time in half, or maybe even cut it to 1/3 of what it takes today, at least for some projects?

Every one of you can answer that because almost all of you upgraded, in the last few releases, at least in part to get GPU support which promised to deliver just that. For many of you, it has delivered on that promise, and you'd never go back. Here is something that can do just that, and without requiring any hardware upgrades.

Yes, creating the code is complicated, but it is actually less complicated for the people who own the code and, presumably, understand how the thing is put together "under the hood."

If I were the product manager for Sony Vegas, I'd put this at the top of the list, and in the next release I'd tout a 2-3x improvement in both renders and timeline preview performance, at least in some situations where multiple tracks are involved.

It is interesting how this revelation has changed my thinking about Sony Vegas. I now view every additional track of video as a liability, one that must be fully examined and managed.

Since many of you are voting that it is not a bug, I guess you are willing to live with the horrible timeline performance hit that this lack of "aware programming" is giving you, as well as potentially huge increases in render times. As a customer, and ex-product manager, I find it totally unacceptable.

If SCS cares about its customer, it will make this problem go away, whether they want to call it a bug, or not.

@Marco - Brilliant! That approach would probably be the best as I am in the camp that getting AI to determine composite go/no-go is difficult with all of the various possibilities of composite layers. As mentioned earlier, there would be blood if the AI decided a no-go and there should have been. SCS has taken the "brute force but always works" approach.... which is legitimate. (I do a lot of programming professionally.)

As in my first response to johnmeyer as the OP of this thread, again I don't think there is a bug here so much as healthy examination of the priority of the SCS choices in coding to make this a useful NLE with built-in compositing.

John, I have sympathy with your most recent post above, but again something akin to calling out SCS for setting difficult priorities does not just lie in the province of a few opinions. How does SCS set the priorities for coding choices? Well, let's take the most recent obvious example in the latest build 428 for VegasPro13. What was the priority for that release? The unification with the latest release of the companion app Ultimate S4? Surely that had not been the priority just a few months prior. Seems to be an ever-changing balance for coders.