How to get Vegas 12 to fire on all four cylinders?

Terje wrote on 11/13/2012, 5:32 PM
My current desktop is a (rather old admittedly) quad core thingy with plenty of RAM etc. It runs Vegas 12 perfectly, but rendering can be a bit on the slow side. Currently, for example, I am rendering a project that contains six nested projects, each of these with footage with transparency etc. The rendered framerate is about 1 frame per second, in other words about 1/25th of real time.

Given that I have no GPU acceleration on this one, I am not that surprised that it is slow (a little that it is THAT slow). However, when I take a peek at my CPU utilization, I am disappointed to see that they run at between 25 and 34%. In other words, not really really fast. I have tried with a number of setting for rendering threads, but find they have little impact (unless you go to one).

Any ideas?

Comments

john_dennis wrote on 11/13/2012, 6:04 PM
I have a similar interest considering that I have a modern system and have been unable to saturate all the cores while rendering even with six simultaneous instances of Vegas Pro 12.

http://dl.dropbox.com/u/40618156/For%20SCS%20Forum/Render%20Screen%20Capture.png

It's on my list of things to do...

My main system:
Motherboard: Asus X99-AII
CPU: Intel i7-6850K
GPU: Sapphire Radeon RX480-8GB
RAM: Corsair Dominator (4 x 4 GB) DDR4 2400
Disk O/S & Programs: Intel SSD 750 (400 GB)
Disk Active Projects: 1TB & 2TB WD BLACK SN750 NVMe Internal PCI Express 3.0 x4 Solid State Drives
Disk Other: WD Ultrastar/Hitachi Hard Drives: WDBBUR0080BNC-WRSN, HGST HUH728080ALE600, 724040ALE640, HDS3020BLA642
Case: LIAN LI PC-90 Black Aluminum ATX Full Tower Case
CPU cooling: Corsair Hydro series H115i
Power supply: SeaSonic SS-750KM3 750W 80 PLUS GOLD Certified Full Modular Active PFC Power Supply
Drive Bay: Kingwin KF-256-BK 2.5" and 3.5" Trayless Hot Swap Rack with USB 3
Sound card: Crystal Sound 3 on motherboard. Recording done on another system.
Primary Monitor: Asus ProArt PA248q (24" 1920 x 1200)
O/S: Windows 10 Pro 22H2, Build 19045.2130

Camera: Sony RX10 Model IV

https://www.youtube.com/user/thedennischannel

dxdy wrote on 11/13/2012, 6:21 PM
Rendering a project that contains nested projects is slower than rendering a project without nested projects. In my experience, by a factor of 4.

The template you are using makes a huge difference. The speed of your disks, and the number of disks, memory speed and timings, they all enter into the mix.
Terje wrote on 11/13/2012, 6:30 PM
So, you are basically saying, drop the nested project stuff, render to some more or less lossless format and do the final render with the intermediate renders.
farss wrote on 11/13/2012, 7:20 PM
If the CPU isn't working hard something else is the bottleneck.
First thing I'd consider is the disk system thoughput especially when lots of media from different source files is involved.

Bob.
ushere wrote on 11/13/2012, 7:53 PM
i somehow never thought of vegas pro as 'four cylinder', maybe movie studio...

i'd think vegas was more a refined six cylinder, and something along the lines of fire / flame / smoke 12.

that said, 11 ran like an east german 3 cylinder and 12 is more a sort of wankel, great on paper but not quite the same in real life....

ah, render due to finish....
wwaag wrote on 11/13/2012, 8:36 PM
"Rendering a project that contains nested projects is slower than rendering a project without nested projects. In my experience, by a factor of 4."

I've had the same experience with nested projects so I don't use them. My solution has been to do a final render for each of the "nested" projects and then combine these using third party software that will smart-render the files together. I use TMPGEnc's MPEG Editor. Similar software is available if your final render format is AVC.

Another way is to use the the stitch option in the Transcoder if you have Vegasaur.

wwaag

AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia 1050ti graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

John_Cline wrote on 11/13/2012, 9:16 PM
There was a thread about four years ago that discussed why all the cores of a CPU were not running at 100% during a render. JohnnyRoy posted the following which is as good an explanation of what's happening as I have heard:

What people who don't understand how computers do multi-tasking don't realize is that multiple cores can only be utilized when the task has steps that can be done in parallel. Work doesn't magically use all of the cores at 100%.

You can read the entire thread here:

www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=586955
wwaag wrote on 11/13/2012, 10:26 PM
FWIW. For grins, I just rendered two nested projects in V12. Total duration was 9:51. Clips were mostly AVCHD (1080 60P), with some MPEG from Proshow Producer and Cineform AVI,s--all were 1080 60P.

First render--internal mainconcept-HDV (1440x1080, 60i). Render time: 16:28. Using task manager--my guess is that average CPU usage was around 80%.

Second render--Debugmode Frameserver to Grass Valley Procoder (IMHO a lot better than MC)-HDV (1440x1080, 60i). Render time: 10:29. Here's what's interesting--my guess is that average CPU usage was around 40%.

Bottom line: Procoder was a lot faster, although CPU usage was dramatically lower--reinforcing John Cline's previous post. Procoder does a lot better at distributed processing.

wwaag

AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia 1050ti graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

dxdy wrote on 11/14/2012, 2:18 PM
@Terje:

Nesting is a great tool for editing, but remember that at render time, all the rendering work still has to be done on the nested projects as well as the top level project. So rendering the nested projects out to a good intermediate really does not cost you time.

As an experiment, I tried running the New Rendertest both nested and not, with and without GPU on my 3770k with GTX 660ti:


1. Rendertest from internal SATA to USB3 no GPU:
Elapsed time 3:23, averaging 0% gpu, 65% cpu NOT NESTED
Elapsed time 4:31, averaging 0% gpu, 16% cpu NESTED

2. Rendertest from internal SATA to USB3 Rendertest.veg with GPU
Elapsed time 0:36, averaging 70% gpu, 50% cpu NOT NESTED
Elapsed time 0:55, averaging 50% gpu, 16% cpu NESTED


There is a measurable difference on this machine in elapsed time, although nowhere near the 400% I have seen on less powerful machines in the past. Very interesting that GPU made a huge difference.

Edit to fix a header
Former user wrote on 11/14/2012, 2:23 PM
I avoid nesting at all costs. You can render to an uncompressed file far quicker than any compressed file. If disk space is a concern, you can always delete the uncompressed when you are done, plus in video, if disk space is a problem, then the computer needs to be upgraded. You just have to have a lot of disk space in this field.

I use uncompressed for all intermediate files.

Dave T2
Guy S. wrote on 11/14/2012, 3:48 PM
<<So, you are basically saying, drop the nested project stuff, render to some more or less lossless format and do the final render with the intermediate renders.>>

YES!

I render to the .mxf format - the quality is excellent and Vegas handles this format really well. I use the HDCAM EX preset but others might work just as well for you.

If you get a video card to help accelerate timeline playback and rendering performance you may want to try V12's MP4 rendering format. The quality is good and it renders quickly.
Terje wrote on 11/15/2012, 5:14 PM
farss >> If the CPU isn't working hard something else is the bottleneck

Doesn't seem like it. Seems like it is poor execution of rendering nested projects within Vegas. Proof? I think so. I fire up five instances of Vegas, one for each of the nested projects. I kick of rendering for all of them, and voila, 100% of CPU used, and the render of the combined projects is significantly faster than rendering it from the "mother" project.

Given the fact that the easiest way to split the render into multiple threads would have been for Vegas to essentially do what I do, render each project in a different thread and stitch at the end of the last render.

For nested projects at least, it seems SCS has a potential of about a 200% speed increase by just fixing the threading issues Vegas apparently has for nested projects. Considering that this is a significantly safer route to go than adding GPU rendering into the mix (obviously, see the complaints department) it would probably behoove SCS to look into this.

Think about the messages you are reading in this thread alone "never do nested projects", "nested projects don't work", "nested projects a nightmare to render".

I love Vegas, and I since 12 I am back to using it as my main video editor, but if it can't handle nested projects properly, that might change. SCS needs to focus on where they lag the competition and where they are strong. Premiere has "nested projects" and the execution is (comparatively) flawless (not in an absolute sense, I know) and other neat things. Does Vegas do render queues? It's a good idea. Instead of having to fire up four instances of Vegas and render in parallel I could have added them to a render queue, and had the master project render from the pre-rendered (MXF for example) video files. That would have been nice.

So, here is what I put on the top of my wish list for Vegas 13:
1/ Fix nested projects, if your users say "never use nested projects", you have failed badly. Nested projects is a very, very good way to work. In fact, look at Premiere. Adobe does this the right way, SCS not so much.
2/ Check out the threading stuff, seems like there is some enhancements needed
3/ Fix the apparent (but not seen by me) problems with GPU rendering
4/ Stop making me have to agree to the license terms each and every time I run Vegas. I know, I am on Windows 8, but I agree, I promise. Once is enough.

I'd pay for an upgrade if only 1 was fixed.
videoITguy wrote on 11/15/2012, 5:25 PM
I would not pretend for a moment to know threads, cores, and CPu cycling...but, there could be a point here, IF I know the real score on programming this kind of feature. That is a lot of underthe hood examination. WOULD assigning a thread per nested project be possible? ON all makes of CPU's with multiple cores? Can it be that simple?

Ok, if it is, then go for it and goodness gracious, lets get rid of this GPU bamboozlement!
Terje wrote on 11/17/2012, 12:21 AM
>> WOULD assigning a thread per nested project be possible

Basically, yes. The only issue would be GOP size I think. Here I am a little out of my depth. I know a lot about programming and a lot about concurrent (many threads) programming, but I am not quite as well informed on the intricacies of low-level video formatting. The question is simply, could a movie have different sized GOPs? In other words, is it OK to make a movie that in one place has a 12 frame GOP and in another it has a 6 frame GOP? If that is OK, it is simply a question of rendering each nested project in a separate thread. If there are huge differences in the size of the nested projects, as a thread finishes one it might start on something else.

If all GOPs have to be the same length in the final product, you would have to do some (as far as I can see extremely simple) math to determine where in the GOP the stitching would occur and then create the first few frames of a project based on an I-frame from the previous project. I do think that most output formats support variable length GOPs, though, so it shouldn't be necessary.

The issue arises because if you render these completely independently, where they "but up" against each other, the GOP could vary in length.