PC resources not being utilized well by Vegas

tim-neighbors wrote on 10/9/2021, 11:47 AM

I bought a new, fairly beefy workstation. It wasn't playing back the Vegas timeline w/effects very impressively at all. My brother came over, we saw that it wasn't making good use of the computer's beefy resources, he tweaked different settings in Windows and Vegas and got it working beautifully. Was quite impressive. But I had to get the computer replaced with the exact same model -all components exactly the same. The new system is having the same issues, where Vegas doesn't seem to be making good use of it's resources at all. My brother came over and we tried tweaking things as before, but this time no luck. Any ideas of what we could try?

Using VP19

Dell Precision 7820 Tower
Intel Xeon Gold 5220R CPU @2.20GHz, 2195 Mhz, 24 Cores, 48 Logical procs.
Windows 10 Pro for Workstations
64GB memory
Solid State drive via USB3
NVidia P2200 Graphics card

Is there a site with any common PC tuning tips for Vegas? The footage I'm trying to play is .MXF UHD footage from a Sony FX6. Is there some codec package I should install that'll allow me to play it more efficiently or something? I can see and work with the video, so my thought is it's not a codec issue, but maybe I'm wrong?

We ran multiple 3D benchmark tests and all were fine, but VP continues to perform poorly with this footage even though we enabled GPU acceleration. The FX6 footage doesn't seem to make any use of the graphics card -had really low utilization overall (no cores being pegged, disk utilization was low. We tested the hard drive/cable/port and it seems fine.

Back to post

Comments

RogerS wrote on 10/14/2021, 12:08 AM

What does sucked mean? The second screenshot suggests it is corrupted though your first one above looked okay and shows some GPU activity. Does it work with GPU decoding after rewrapping to mov?

Former user wrote on 10/14/2021, 12:22 AM

@RogerS

"Did you try Todd's rewrapping advice first?"

MOV sucked on my machine.

@john_dennis I had heard MOV behaved worse then MP4, but when I tried it, seems to work the same as mp4 with the Poster's rewrapped .mxf. Incidentally @tim-neighbors when I tried VP19 I had more slow frame rate problems then VP18, so went back to VP18, also my test was in VP18. Some here are suggesting you need faster core frequencies, and I guess that could be true, but surely at the low cpu use, you're probably at 4ghz and that's not slow, not 5ghz, but not slow either.

john_dennis wrote on 10/14/2021, 12:24 AM

Video corruption or decode issue causing poor video in the preview with MOV rewrap.

tim-neighbors wrote on 10/14/2021, 8:48 PM

Until something happens at Magix with the decoding, I'd be prone to use MagicYUV RGB. Customize a template for FHD-59.94p and use Happy Otter Scripts/Proxy Assist to create proxies. For MagicYUV RGB you'll need fast disks. Your USB may not be fast enough or may have high latency with those I/O rates.

I would return the Xeon machine and get one with 8-10 cores that run at a higher clock rate.

I had a similar issue with Canon video in an MXF wrapper in 2017. The result was one of the reasons I didn't buy a Canon XC15 and finally bought a Sony RX10-IV.

https://www.vegascreativesoftware.info/us/forum/uhd-4k-timeline-preview-results-2017--105232/#ca650778

ugh. My shoots typically involve capturing a lot of footage, rendering out beefy proxies for all of those files would take me a lot of extra time and hdd space and might be impractical for many projects. :(

Did you try Todd's rewrapping advice first?

Did you determine if your camera can output other formats than MXF with the features/settings you need?

I just rewrapped a clip as .MOV and it worked much better! The GPU is now engaged and it plays back well. But now I'm getting a lot of black flashes and the system crashed once. When I render a video out, the black flashes come out in the render as well. I guess I'd have to disable graphics acceleration when I'm ready to render? Or maybe the graphics card is underperforming?

tim-neighbors wrote on 10/14/2021, 8:54 PM

Yeah, unfortunately the .mov rewrap seems to make Vegas unstable. lots of black and red flashes and crashes.

john_dennis wrote on 10/15/2021, 2:01 AM

Shutter Encoder ProRes Proxy 1) encodes rather quickly, 2) exposes all four channels as mono tracks, 3) produces a file about the size of your source and plays much faster on the Vegas 19 timeline than your Canon files. *

* Even with a Handbrake render using 100% of my CPU.

Try it.

Former user wrote on 10/15/2021, 7:15 AM

Yeah, unfortunately the .mov rewrap seems to make Vegas unstable. lots of black and red flashes and crashes.

I did see those black flashes, but didn't think it would appear in the render. So the anti .mov people are proven right, Vegas does not handle .mov well

john_dennis wrote on 10/15/2021, 8:24 AM

"Vegas does not handle .mov well"

Not true. The efficacy with which Vegas handles .MOV depends on what's inside the wrapper. I have thousands of media files in a .MOV wrapper from a Canon camera that Vegas handled just fine in 2013 without Quicktime.

Vegas 9

General
Complete name                            : D:\_Photos\2013\2013-05-26 CA Capitol\MVI_0439.MOV
Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   2007.09 (qt  /CAEP)
File size                                : 136 MiB
Duration                                 : 30 s 948 ms
Overall bit rate                         : 36.9 Mb/s
Encoded date                             : UTC 2013-05-26 23:09:32
Tagged date                              : UTC 2013-05-26 23:09:32
Copyright                                :         
com.apple.quicktime.make                 : Canon
com.apple.quicktime.model                : Canon PowerShot G15
com.apple.quicktime.author               :         

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : Baseline@L4.1
Format settings                          : 1 Ref Frames
Format settings, CABAC                   : No
Format settings, Reference frames        : 1 frame
Format settings, GOP                     : M=1, N=12
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 30 s 948 ms
Bit rate                                 : 35.3 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.711
Stream size                              : 130 MiB (96%)
Language                                 : English
Encoded date                             : UTC 2013-05-26 23:09:32
Tagged date                              : UTC 2013-05-26 23:09:32
Color range                              : Full
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
Codec configuration box                  : avcC

Audio
ID                                       : 2
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : sowt
Duration                                 : 30 s 948 ms
Bit rate mode                            : Constant
Bit rate                                 : 1 536 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 5.67 MiB (4%)
Language                                 : English
Encoded date                             : UTC 2013-05-26 23:09:32
Tagged date                              : UTC 2013-05-26 23:09:32

RogerS wrote on 10/15/2021, 9:47 AM

Same here, I have plenty of Canon and Panasonic AVC in a mov wrapper that decodes with s04compound without issue.

tim-neighbors wrote on 10/22/2021, 7:21 PM

There's no reason the GPU should not be able to decode this video, being 8 bit 4:2:0 AVC. I'll pass it along to the dev team.

The GPU is also not being employed with this codec from a Sony A7siii, which is a very popular camera. Here are the specs for that:

General
Complete name : H:\InSync\Invisible Harness\Client Projects\ANW\2021-10_Seven Guitars\Footage from Malcolm\4K raw\C1570.MP4
Format : XAVC
Codec ID : XAVC (XAVC/mp42/iso2/nras)
File size : 29.6 GiB
Duration : 1 h 21 min
Overall bit rate : 52.0 Mb/s
Encoded date : UTC 2021-10-16 23:56:01
Tagged date : UTC 2021-10-16 23:56:01

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 1 h 21 min
Bit rate : 45.0 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.091
Stream size : 25.6 GiB (87%)
Encoded date : UTC 2021-10-16 23:56:01
Tagged date : UTC 2021-10-16 23:56:01
Color range : Limited
Transfer characteristics : BT.709
Codec configuration box : hvcC

Audio
ID : 2
Format : PCM
Format settings : Big / Signed
Codec ID : twos
Duration : 1 h 21 min
Bit rate mode : Constant
Bit rate : 1 536 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 896 MiB (3%)
Encoded date : UTC 2021-10-16 23:56:01
Tagged date : UTC 2021-10-16 23:56:01

Other
Type : meta
Duration : 1 h 21 min

tim-neighbors wrote on 10/22/2021, 7:46 PM

Until something happens at Magix with the decoding, I'd be prone to use MagicYUV RGB. Customize a template for FHD-59.94p and use Happy Otter Scripts/Proxy Assist to create proxies. For MagicYUV RGB you'll need fast disks. Your USB may not be fast enough or may have high latency with those I/O rates.

I would return the Xeon machine and get one with 8-10 cores that run at a higher clock rate.

I had a similar issue with Canon video in an MXF wrapper in 2017. The result was one of the reasons I didn't buy a Canon XC15 and finally bought a Sony RX10-IV.

https://www.vegascreativesoftware.info/us/forum/uhd-4k-timeline-preview-results-2017--105232/#ca650778

ugh. My shoots typically involve capturing a lot of footage, rendering out beefy proxies for all of those files would take me a lot of extra time and hdd space and might be impractical for many projects. :(

Did you try Todd's rewrapping advice first?

Did you determine if your camera can output other formats than MXF with the features/settings you need?

This camera doesn't have many recording options. This is all of them and they are all recorded with the .MXF wrapper.

XAVC-I 4:2:2 10-Bit:
4096 x 2160p at 23.98/24/25/29.97/50/59.94 fps (240 to 600 Mb/s)
3840 x 2160p at 23.98/25/29.97/50/59.94 fps (240 to 600 Mb/s)
1920 x 1980p at 23.98/25/29.97/50/59.94 fps (89 to 222 Mb/s)
XAVC-L 4:2:0 8-Bit:
3840 x 2160p at 23.98/25/29.97/50/59.94 fps (100 to 150 Mb/s)
XAVC-L 4:2:2 10-Bit:
1920 x 1080p at 23.98/25/29.97/50/59.94 fps (35 to 50 Mb/s)

Former user wrote on 10/22/2021, 7:57 PM

There's no reason the GPU should not be able to decode this video, being 8 bit 4:2:0 AVC. I'll pass it along to the dev team.

The GPU is also not being employed with this codec from a Sony A7siii, which is a very popular camera. Here are the specs for that:

General
Complete name : H:\InSync\Invisible Harness\Client Projects\ANW\2021-10_Seven Guitars\Footage from Malcolm\4K raw\C1570.MP4
Format : XAVC
Codec ID : XAVC (XAVC/mp42/iso2/nras)

Vegas is full of bugs that will never get fixed, I don't understand why, but it's the way it is. People that use it either grew up with it and don't want to adapt to another editor or they use it because it's the most intuitive and easy to learn.

As for this bug, I think GPU decoding is supposed to work if you have GPU decoder set to Intel IGPU, but it doesn't work with GPU decoder set to AMD or Nvidia GPU's. This is the HEVC 10bit 420 GPU video bug.

One thing I'd say is don't use HEVC unless you need to, such as the very high frame rates that are only available in HEVC mode. Use AVC Intra modes for easiest playback without a GPU decoder

RogerS wrote on 10/22/2021, 8:05 PM

No decoding with MXF containers doesn't seem like a bug but rather an unimplemented feature. It doesn't decode with Intel here

HEVC is a separate issue and I expect decoding support will improve.

Mohammed_Anis wrote on 10/22/2021, 9:16 PM

If none of this works, just proxy the files and make sure the preview quality is on

Preview -> Best or Half or Quarter

Good/Best plays the resolution at a native level, therefore ignoring proxies completely.

Preview and Draft switch to an old temporary format that VEGAS likes and it looks decent enough for any footage.

If you're color grading, I suggest you switch to best. Grade and go back to preview when you want to see it in motion or render a few seconds of it.

tim-neighbors wrote on 10/22/2021, 11:02 PM

If none of this works, just proxy the files and make sure the preview quality is on

Preview -> Best or Half or Quarter

Good/Best plays the resolution at a native level, therefore ignoring proxies completely.

Preview and Draft switch to an old temporary format that VEGAS likes and it looks decent enough for any footage.

If you're color grading, I suggest you switch to best. Grade and go back to preview when you want to see it in motion or render a few seconds of it.

yeah, I know. It's just a shame to have to be building proxies with all of my 4K footage even after spending $5K on a new workstation.

Former user wrote on 10/23/2021, 4:35 AM

@tim-neighbors

One thing I'd say is don't use HEVC unless you need to, such as the very high frame rates that are only available in HEVC mode. Use AVC Intra modes for easiest playback without a GPU decoder

Welcome to my world 😂, I bought a PC for £9k ( US $12424.08) Specs are in my signature,

it'll play an unaltered vid at Best Full no prob, but it doesn't play well with an effect added at Good Full, sometimes even at Good Auto 😕 I've tried quite a few settings, the Taskmanager shows Vegas using only a small part (1/3) of the PC's potential while it struggles play,,

As todd-b says I avoid HEVC files & rendering, my machine seems to like AVC/AAC not HEVC/AAC

I render out using MAGIX AVC/AAC MP4, I find it plays back with no prob when imported back into Vegas.

Rendering using the option with (HVENC) at the end is faster but can be a little unpredictable with images/text added to the MP4 clip in the timeline, the rendered clip has them mixed up or flicking backwards n forward,

Rendering using the one above that doesn't have the (HVENC) at the end is more stable, the rendered project is as in the timeline but is a little slower & makes my CPU Max out, 100%

I expected this machine to make Vegas run as smooth as silk but noooo 🤣 I've got used to just doing a Build Dynamic RAM to make it play better, people have mentioned Prerender but my machine seems to do Dynamic RAM faster

Former user wrote on 10/23/2021, 2:10 PM

@tim-neighbors Just thought i'd share so maybe a bit of context to my comment, this is a 6sec jpg clip, no movement, i've only added S-Ultraglow, masked it (no tracking) so only the headlights glow using the Mocha built in to Ultraglow, 1.12 to render 3840x2160 AVC & my PC is hardly working at all, nowhere near what it could be doing 😕 it should spit out this simple task,

Former user wrote on 10/23/2021, 8:54 PM

@Former user I tried ultra glow using built in mocha to track a rock in both Resolve and Vegas. Performance is bad in both. The bottleneck looks to be the plugin. The same ofx plugin is used in both editors. It's much faster in Adobe Premiere so I conclude it's a limitation of the ofx plugin

Shown in order, Vegas 1/2 resolution, Resolve Full resolution, Vegas 1/4 resolution

Howard-Vigorita wrote on 10/25/2021, 1:09 AM

Been playing with double frame rates and Vegas just doesn't like em much regardless of the format or wrapper. I see hardware decoding happening with mov or mp4 re-wraps but still lackluster performance. Find the best way to handle them on my system is to put the actual clips in a folder and put transcodes into a parallel folder converting them all to single, half, or even quarter-rate 420 mov for edit and later doing media replacement in Project Media to render the final deliverable. Not as convenient as Vegas proxy handling but smoother editing.

My systems are optimized for hevc which is what I normally shoot and edit without proxies for single-rate shoots; so I might knock double-rate hevc down to that for edit. Transcoding double rate stuff to lower rate ProRes Proxy works well too but takes up allot more space and the only thing that'll speed it up is a faster cpu. My advice is don't shoot double rate unless you really need it for slowmo or high speed motion and stick to formats and cameras you know your system can edit.

Btw, there is no hardware that can decode 10-bit avc so always bring that down to 8-bit for edit. But beware that high avc bit rates can cause all kinds of weirdness with hardware decoding which will pass through to renders... using avc legacy decoding might help fix that while still using gpu and will usually run faster with identical results in quality.

Similarly, only the Intel 750/Xe/Iris series can decode 422 hevc in hardware. But it's still pretty pokey so I'd recommend always knocking that down to 420 10-bit at the most for edit. For high bitrates, I've found hevc rock solid in hardware all the way up to lossless. But for a substantial quality boost in renders I switch to hevc legacy decoding for deliverables even though it runs quite a bit slower.

tim-neighbors wrote on 10/25/2021, 1:38 AM

Been playing with double frame rates and Vegas just doesn't like em much regardless of the format or wrapper. I see hardware decoding happening with mov or mp4 re-wraps but still lackluster performance. Find the best way to handle them on my system is to put the actual clips in a folder and put transcodes into a parallel folder converting them all to single, half, or even quarter-rate 420 mov for edit and later doing media replacement in Project Media to render the final deliverable. Not as convenient as Vegas proxy handling but smoother editing.

My systems are optimized for hevc which is what I normally shoot and edit without proxies for single-rate shoots; so I might knock double-rate hevc down to that for edit. Transcoding double rate stuff to lower rate ProRes Proxy works well too but takes up allot more space and the only thing that'll speed it up is a faster cpu. My advice is don't shoot double rate unless you really need it for slowmo or high speed motion and stick to formats and cameras you know your system can edit.

Btw, there is no hardware that can decode 10-bit avc so always bring that down to 8-bit for edit. But beware that high avc bit rates can cause all kinds of weirdness with hardware decoding which will pass through to renders... using avc legacy decoding might help fix that while still using gpu and will usually run faster with identical results in quality.

Similarly, only the Intel 750/Xe/Iris series can decode 422 hevc in hardware. But it's still pretty pokey so I'd recommend always knocking that down to 420 10-bit at the most for edit. For high bitrates, I've found hevc rock solid in hardware all the way up to lossless. But for a substantial quality boost in renders I switch to hevc legacy decoding for deliverables even though it runs quite a bit slower.

That's a lot of fantastic info. Thank you!