Vegas 21 v300 Very Slow Render on NUC X15 Notebook

dennismf wrote on 4/11/2024, 9:33 PM

Yesterday I updated my Vegas 21 365 installation from v208 to v300. v300 worked well while I was editing my current project. However, when I tried to render the video, I found that the render was about 1/3 of the speed on the previous version (v208).

My project is UHD shot on a Panasonic GH5 in HLG. My Vegas project is set to render in UHD HDR10 using Aces..I am using the Mainconcept HEVC encoder.

I measured the difference between the two versions: I took a single event and rendered it using v300.

With the Intel ARC A730M GPU selected, the render took 7:18 to complete at an average frame rate of 1.41fps.
With the Intel Iris Xe GPU selected, the render took 7:38 to complete at an average frame rate of 1.34fps.

After restoring from an Acronis backup of my computer that was taken shortly before I installed v300, i rendered the same event again in v208.

With the Intel ARC A730M GPU selected, the render took 2:21 to complete at an average frame rate of 4.42fps.
With the Intel Iris Xe GPU selected, the render took 8:51 to complete at an average frame rate of 1.17fps.

Note that v208 is around 3 times faster than v300 using the ARC A730M.

When I render using v208 and earlier, my CPU runs hot at around 93 degrees but the CPU usage only averages 86%. The clock rate remains high for this computer at around 3.9ghz. The A730M GPU is around 38% utilised.

When I render using v300, my CPU runs at around 80 degrees but the CPU usage is 100% (all cores fully utilised). The clock rate is lower at around 2.9ghz. The A730M GPU is around 6% utilised.

I now cannot open my current project in v208 as the project file was significantly updated yesterday using v300.

I am happy to act on any suggestions. I hope that the Vegas team can resolve this problem. It is possible this issue only affects Intel ARC GPUs.

My computer is an Intel NUC X15 i7 notebook with 64GB of ram and a 12th gen CPU. It is running Windows 11 with the latest Microsoft and Intel updates.

Thanks and Regards

Dennis MF

Comments

RogerS wrote on 4/12/2024, 12:36 AM

In general I found Intel decoding performance dropped from 208 to 300 which could also affect renders (slower to read= slower to write)

You could try "enable legacy AVC" decoding in preferences, file io and see if the older decoder helps any.

Edit: Otherwise it may be an issue with AMD x color grading panel in 32-bit ACES mode I saw someone else write about.

You may need to wait for a future version to restore performance.

Feel free to also try and fill out either of the benchmarks in my signature; we can compare it against similar systems.

If it's just an issue with the render, as a workaround you may find a hardware encoder through Voukoder might give you acceptable quality with much better performance? I find its QSV quite a bit better than what is in VEGAS. Just download the program (non-"pro") and connector for 21. https://www.voukoder.org/

Wolfgang S. wrote on 4/12/2024, 4:17 AM

@dennismf

could you be so kind and post some more informations:

a) snapshoot of a Mediainfo print with your footage

b) Preferences/Video that you use in b300

c) Preferences/ File I/O that you use in b300

d) snapshoot of the exakt render template you used in the Magix HEVC/AAC mp4 Endcoder. With or without QSV?

And - do you use the CGP to grade your footage?

RogerS wrote on 4/12/2024, 4:47 AM

Here's how to provide MediaInfo for your main media: https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-vegas-pro-file-properties--104561/

Howard-Vigorita wrote on 4/12/2024, 4:29 PM

@dennismf You might want to take a look at the gpu selected for decoding on the i/o preferences screen and see if the default selection changed as a result of the update. The update seems to now default the i/o decoding gpu to the same one selected in video prefs. With Intel Arcs and igpus, I usually get better performance with the old default which made them different from one another. But on my laptop with a 3060 gpu and IrisXe igpu, the new default seems to be working better. Suggest you try it both ways and see if it makes a difference.

ALO wrote on 4/12/2024, 5:58 PM

@dennismf You might want to take a look at the gpu selected for decoding on the i/o preferences screen and see if the default selection changed as a result of the update. The update seems to now default the i/o decoding gpu to the same one selected in video prefs. With Intel Arcs and igpus, I usually get better performance with the old default which made them different from one another. But on my laptop with a 3060 gpu and IrisXe igpu, the new default seems to be working better. Suggest you try it both ways and see if it makes a difference.

I don't feel that we (Vegas end users) are being well-served with such a large set of configuration options. It should not be the case that every time a new update (not even new version!) comes out, we have to become scientists checking and unchecking config boxes to try to find a working combination for our preferred media and render types. It's exhausting and not at all a good use of our time.

RogerS wrote on 4/12/2024, 8:43 PM

Agree. Really the defaults are optimal unless something breaks. Here something broke with the new decoder in build 300. Leave the testing to beta testers.

In this case though would be great if the OP could help narrow down where the performance hit is coming from. Decoding? Encoding? ACES with CGP?

dennismf wrote on 4/12/2024, 8:47 PM

Responding to info request from Wolfgang:

I do use the CGP. I set general grading settings at the Video Bus level and I make event specific adjustments at the Event level. In this project all CGP settings are on the Utilities tab at both Event and Video Bus level. Screen shots are included below, together with the other requested details.

Color Grading is the only Fx in use with this event and at Video Bus.

I have assumed that the Mediainfo requested is the Media tab on the event properties. Have also included output from the program Mediainfo

Text output from Mediainfo program:

General
Complete name : D:\No Backup\Video Projects\2024-01-28 Tasman Peninsula Boat Trip\Media\P1299377.MP4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (mp42/avc1)
File size : 475 MiB
Duration : 25 s 920 ms
Overall bit rate mode : Variable
Overall bit rate : 154 Mb/s
Frame rate : 25.000 FPS
Encoded date : 2024-01-28 10:17:00 UTC
Tagged date : 2024-01-28 10:17:00 UTC

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2@L5.1
Format settings : CABAC / 1 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 1 frame
Format settings, GOP : M=1, N=12
Format settings, Slice count : 16 slices per frame
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 25 s 920 ms
Bit rate mode : Variable
Bit rate : 149 Mb/s
Maximum bit rate : 180 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.718
Stream size : 460 MiB (97%)
Encoded date : 2024-01-28 10:17:00 UTC
Tagged date : 2024-01-28 10:17:00 UTC
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant
Codec configuration box : avcC

Audio
ID : 2
Format : PCM
Format settings : Big / Signed
Codec ID : twos
Duration : 25 s 920 ms
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 : 4.75 MiB (1%)
Encoded date : 2024-01-28 10:17:00 UTC
Tagged date : 2024-01-28 10:17:00 UTC

Other
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 25 s 920 ms
Bit rate mode : Constant
Frame rate : 25.000 FPS
Time code of first frame : 13:01:39:11
Time code of last frame : 13:02:05:08
Time code, stripped : No
Encoded date : 2024-01-28 10:17:00 UTC
Tagged date : 2024-01-28 10:17:00 UTC

dennismf wrote on 4/12/2024, 9:53 PM

I have completed a few more tests to try and isolate the cause:

I repeated my test using the Apple ProRes HQ encoder. This was marginally faster at 1.47fps but I would expect this to be a little faster as ProRes is not as heavily compressed as HEVC. I suspect the issue is not within the HEVC encoder.

In File IO there are two GPU decoder options. "Raw Processor" was auto set to the Intel ARC GPU. "Hardware Decoder" was set to Iris Xe GPU. I changed to to be Intel ARC for both. This produced the same result as Iris Xe.

On the General preferences the option "Use GPU processing for ACES Color Management" was checked. On previous versions and builds I needed to turn this off to avoid issues with the display of titles (both perview and rendered). This option always defaults to on when a new version is installed. On build 300 I found that the problem with displaying titles had been fixed so I left it on. I tested again with it turned off and there was a marginally slower frame rate.

None of these tests identified a particular problem area. I suspect that build 300 is now making little use of the Intel ARC GPU. In build 208 my test using the Intel Iris Xe GPU rather than the ARC produced a result comparable to using Intel ARC in build 300.

Howard-Vigorita wrote on 4/12/2024, 10:39 PM

@dennismf The MediaInfo you posted indicates 10-bit 4:2:2 Avc . That cannot be decoded in hardware by a gpu. Possibly the raw processor might be used but the name suggests it's only to assist in decoding raw footage like Braw. You might try setting the decoder to Off so it doesn't spin its wheels on the impossible. But only if you don't put 8-bit 4:2:0 Avc or any kind of Hevc on your timeline.

Wolfgang S. wrote on 4/13/2024, 2:37 AM

Yes, that is the issue maybe. 10bit AVC 422 is not decoded by the Intel GPU, but also not by the i-GPU.

https://www.intel.com/content/www/us/en/docs/onevpl/developer-reference-media-intel-hardware/1-1/overview.html#DECODE-OVERVIEW-DISCRETE

This will result in a poor performance with the new decoder. Maybe the legacy AVC decoder is better here.

So the solution for the future could be, to shoot in a format that is supported better at the moment. Maybe, upcoming updates with Vegas will perform here better, since the video enginee in Vegas is reworked at the moment, but this will take much more time (a year or so?)

You will not find a media template for HLG in the media settings, but you find one for v-log/v-gamut for Panasonic what works great. The second best choice for this footage seems to be what you have choosen anyway - rec2020 hlg.

Also, to shoot in HLG is never a good idea due to the transform function that is not great for grading - much better would be to shoot in v-log with your GH5. Maybe to all-i avc 10bit

RogerS wrote on 4/13/2024, 7:41 AM

I'm surprised you're seeing worse results with AVC 10-bit 4:2:2.

I saw Frosty post it was much better in 21.300 than before and I also find it much more editable, even though there is no GPU decoding whatsoever.

Because of that neither raw decoder (for Braw) nor hardware decoding should have any affect on the playback.

On my desktop system (13th gen Intel CPU + RTX 2080), I loaded a A7SIII 10-bit 422 4K AVC file I have and changed the settings to ACES (ACEScc). It played back at a full 23.976fps. I added CGP and it dropped to 1 FPS.

Without CGP it was at 30% CPU and 60% GPU usage.
With CGP it was at 100% CPU and 15% GPU.

Tried the same test with GH5 10-bit 422 AVC and got the same result though closer to 10% GPU usage with CGP on.

I think the issue, at least here, is that the CGP isn't currently correctly using GPU resources.

To test the theory I picked very easy media to decode, 8-bit 4:2:0 XAVC-S (4K24p).
Still in ACES mode I selected Rec709 color space and played it back- perfect 23.976 throughout.

Added the CGP and it droped down to 1fps again and I heard my CPU fans spin up.

Even in 8-bit full my 14 core CPU is at 100% when CGP is active making it barely playable at full speed (best/full).

Until GPU support for the CGP is fully restored I'd bypass it when doing editing vs color correction.

Wolfgang S. wrote on 4/13/2024, 8:02 AM

That is a possible second issue. And that is why I have asked, if the CGP is in use.

It can be tested easily - as shown here: by disabeling the CGP for testing on an event level.

And unfortunately yes - we see significant performance drops when the CGP is applied. At least at the moment.