Vegas 21 fails to correctly recognize GPU, no preview acceleration

Arik-Drori wrote on 11/20/2023, 4:40 PM

I have total of 3 GPUs in my system:

Win 10 64bit with an AMD 7950x CPU with its own internal GPU (on Asus creator x760e wifi MotherBoard) - no monitors connected, an RTX 4060ti as the main GPU with 3 monitors connected, and an RTX 3060ti with no monitors connected.

I have Topaz video AI installed, and to use its multi GPU feature I need to disable the AMD internal GPU, or it slows everything down.

When running Vegas 21, I get a black screen on the preview window.

If I disable GPU preview acceleration - it works fine. but if I wish to enable it, I see only the 4060ti as acceleration option. Not the 3060ti. And when I select the 4060ti - I get the black screen.

If I enable the AMD internal GPU in windows device manager, I have two options to choose from in Vegas 21: AMD and 4060ti. Now they both work, no black screen, but still I cannot see the 3060ti. However, this is not useful as I need the AMD GPU off in device manager for Topaz video AI.

So:

1. Why can't vegas see the 3060ti?

2. Why a black screen with the 4060ti when the AMD GPU is disabled?

I can work for now with the GPU acceleration off, but, really, this is unacceptable. These problems haven't been addressed for years! I had similar issues (different cards, having eventually to turn off the acceleration) for YEARS. Ver 15, Ver 18, and now Ver 21. It's time to address this.

I'm not sure the acceleration works at all, because even with the acceleration turned on, the timeline is not rendered fluently. It can be fine and then suddenly freeze (the audio continues, you can see the dots (.....) appear near the frame number in the preview window and the preview is unusable. I have to stop, let it catch up and continue to play back. With a complex timeline it's impossible to get a reasonable preview.

I have an extremely fast PC, with plenty of GPU power, fast NVME v4 drives (Samsung 990 pro, corsair MP600 pro HN) and the timeline still behaves like 4-5 years ago when I started working with 4K video.

Unacceptable.

Please help!!!!

Back to post

Comments

Howard-Vigorita wrote on 11/23/2023, 10:33 PM

Is the low quality hardware decoding a Vegas problem or when you test outside of Vegas you see the same?

@Former user My impression is that it depends on how the hardware decoding is implemented. The most common, highest performance, and easiest technique seems to be to just hand the decoding off to the gpu. That gave me similar lower quality ffmpeg, QsvEncc64, Vegas, and Resolve. The latest Vegas build seems to have souped up the old legacy-hevc which was slow but very high quality, but showed no decoder utilization while 3D utilization increased in task manager. The new decoder seems to show an increase in cpu and 3d utilization as well as decoding. At least on my systems with Intel decoding hardware. Have not gotten a chance to study it on my Xeon yet, which does not have Intel decoding; it uses an Nvidia 1660 for decoding instead.

Former user wrote on 11/24/2023, 12:49 AM

What does it mean, Voukoder not benefiting from 32-bit mode in Vegas?

@Adis-a It means that when I run an objective quality analysis comparing input to output, that little improvement results. I believe it's a general issue with all 3rd party Vegas render plugins resulting from the limited bandwidth feed made available to them by Vegas.

@Howard-Vigorita Can you show me your supporting evidence, I don't see that with using a Prores422 sample with high motion encoding to UT lossless video at both 420 and 422 color. It appears Voukoder has the highest quality.

I do see the obvious problem that Voukoder's 422 UT is a higher bitrate, but when comparing the 420 encodes they're about the same, so lets say they're the same. That's quite different to what you're saying

Adis-a wrote on 11/24/2023, 6:57 AM

What does it mean, Voukoder not benefiting from 32-bit mode in Vegas?

@Adis-a It means that when I run an objective quality analysis comparing input to output, that little improvement results. I believe it's a general issue with all 3rd party Vegas render plugins resulting from the limited bandwidth feed made available to them by Vegas.

@Howard-Vigorita

Hm...don't know how to interpret "little improvement results", so I'll be more specific.

Let's say I have a ProRes 4444 XQ as input quality, does Voukoder maintain said quality when rendering to ProRes 4444 XQ if in 32-bit mode? Can you ran such a test, "objective quality analysis" or what have you, and report your findings?

Thanks! :)

Former user wrote on 11/24/2023, 7:53 AM

@Adis-a It means that when I run an objective quality analysis comparing input to output, that little improvement results. I believe it's a general issue with all 3rd party Vegas render plugins resulting from the limited bandwidth feed made available to them by Vegas.

@Howard-Vigorita

Hm...don't know how to interpret "little improvement results", so I'll be more specific.

Let's say I have a ProRes 4444 XQ as input quality, does Voukoder maintain said quality when rendering to ProRes 4444 XQ if in 32-bit mode?

@Adis-a It's more complex then that because Voukoder's prores isn't real prores. It's why I had to encode to UT 'lossless' video, To test Howard's claims about a low quality/compressed data stream going to voukoder the limitation can't be the encoding codec. I found Voukoder's prores422 was inferior to Vegas's real Prores422

Maybe something like that is how Howard got things wrong or maybe he's still right, but in what situation?

I"ll convert some Cinema Raw to ProRes 4444 XQ and encode to UT video again and see if there's any difference. Also maybe he see's the lower quality at 4K, while i'm testing at 1080P, we don't know what Howard is doing.

Adis-a wrote on 11/24/2023, 8:57 AM

@Adis-a It means that when I run an objective quality analysis comparing input to output, that little improvement results. I believe it's a general issue with all 3rd party Vegas render plugins resulting from the limited bandwidth feed made available to them by Vegas.

@Howard-Vigorita

Hm...don't know how to interpret "little improvement results", so I'll be more specific.

Let's say I have a ProRes 4444 XQ as input quality, does Voukoder maintain said quality when rendering to ProRes 4444 XQ if in 32-bit mode?

@Adis-a It's more complex then that because Voukoder's prores isn't real prores. It's why I had to encode to UT 'lossless' video, To test Howard's claims about a low quality/compressed data stream going to voukoder the limitation can't be the encoding codec. I found Voukoder's prores422 was inferior to Vegas's real Prores422

Maybe something like that is how Howard got things wrong or maybe he's still right, but in what situation?

I"ll convert some Cinema Raw to ProRes 4444 XQ and encode to UT video again and see if there's any difference. Also maybe he see's the lower quality at 4K, while i'm testing at 1080P, we don't know what Howard is doing.

@Former user

My main concern is, say, if it truncates 12 bit quality to 8 bit or not. Quality degradation on 5th place after comma doesn't concern me much. :)

Howard-Vigorita wrote on 11/24/2023, 10:26 AM

Hm...don't know how to interpret "little improvement results", so I'll be more specific.
Let's say I have a ProRes 4444 XQ as input quality, does Voukoder maintain said quality when rendering to ProRes 4444 XQ if in 32-bit mode? Can you ran such a test, "objective quality analysis" or what have you, and report your findings?

Thanks! :)

@Adis-a feel free to verify yourself... links to the lossless-hevc clip, software, and results are in my signature. Just note that vmaf gets revised from time to time so I've been sticking to ffmpeg v4 for consistency with the metrics I've captured over the years. At some point I'll start anew with ffmpeg 6 and vp21. And maybe a new reference if I get a larger format camera.

Keep in mind that if you use ProRes as a reference, that it has allot of synthetic content that may or may not be representative of modern 4k and larger sensors which only capture 4:2:0 color data. You could measure deviation with my reference clip by converting it... I think I did that once and put measurements in the charts. Btw, my reference clip was captured from a 4k Sony Exmor mft-sized sensor which delivers raw in log-video range. If you captured raw-to-lossless 4:2:0 from a larger sensor, that might be a better yardstick for apc, full-frame, or medium-format sized sensor cameras.

Former user wrote on 11/26/2023, 12:29 AM

@Adis-a @Howard-Vigorita I converted some digital raw to 4K ProRes 4444 XQ, encoded to 4K 422 UT lossless video, this is the result.

So Vegas wins here, but it's bitrate is also higher. Just not seeing the low quality results that Howard alleges.

Keep in mind that if you use ProRes as a reference, that it has allot of synthetic content that may or may not be representative of modern 4k and larger sensors which only capture 4:2:0 color data.

Dear God you're still saying that. Whenever you bring that up on this board everyone disagree's with you, I link you to a Hollywood colorist who explains why that's not true, but you don't believe him either. That's why I need proof of what you say, because you stubbornly hold on to false beliefs.

EDIT: I messed up here, I forgot to use 32bit FPU, used the default 8bit, Howard's main criticism is not seeing an increase in quality with 32bit, I"ll have to test that again

Howard-Vigorita wrote on 11/26/2023, 12:44 PM

Dear God you're still saying that. Whenever you bring that up on this board everyone disagree's with you

@Former user Ha, ha, lucky to live in a world where I'm at lower risk of being burned at the stake for heresy.

It should be intuitively obvious that if a format delivers more data than the sensor captured, the extra data created in-camera might be suspect. Considering that resources like math resolution, data width, power, and cooling are stripped to the bone in a battery operated camera. And AI enhancement is totally out of the question. Makes it probably the worst place to do that. Given these obvious quality constraining factors, a quality difference should be expected... the challenge being coming up with a methodology to measure it. Do the best I can with the tools I have. The fact that they do measure and quantify an expected difference speaks for itself. Supported by the fact that larger differences are visible in my client screenings... I tend to do mid-course screenings with 8-bit project renders with faster hardware decoding/rendering. But bump up to 32-bit higher-quality decoding/rendering for final pre-delivery screening... the better metrics translating to an added wow-factor that never fails to impress.

Former user wrote on 11/26/2023, 7:54 PM

@Howard-Vigorita Fair enough Howard. On the subject of Vegas's compressed stream to Voukoder and the limitations in quality that may result. I did see a noticeable difference in 444 UT from vegas to 444 UT in voukoder compared to Vegas, but I still question if that's really a problem, it should be known about for sure, but for most they would hope for no quality difference at 420 8/10bit or 422 10/12 bit using 32FPU.

When I redo my test if the results appear similar to each other between Vegas and Voukoder I"ll then do similar to what you do, crop an area of the video and analyze it visually. I noticed the 4K VMAF is giving me 100% quite often in these UT video encoding tests, so not sure I trust it, therefore I was using the normal VMAF model for 4K, which gives lower scores which seems more realistic but maybe I shouldn't be doing that either.

Former user wrote on 11/28/2023, 2:56 AM

@Howard-Vigorita On the left of video is Voukoder Prores444, right is Vegas ProresXQ. It's cropped 2x

Are you able to visually see the huge difference in PSNR values, what would cause that?

Obviously this is 420 8bit Magix server transcode, but because it's low motion and not overly detailed thought it could still have some use

Howard-Vigorita wrote on 11/28/2023, 6:09 PM

@Former user I often see psnr trending in an opposite direction from the other 2 metrics. But every time I look at the footage involved, I either don't see a difference or don't agree with the psnr ranking. But that's a really huge psnr difference you got, more than I've ever come across. It's likely reacting to something within a frame that the other 2 metrics think is unimportant or imperceptible. I don't see it in the section of the frame you zoomed in on... must be somewhere else. The problem psnr is reacting to may be a blank frame, a dropped frame at the end, a burnt highlight, or a blacken shadow or eyelash. I personally think psnr and rms are best suited for micro analysis within still pictures and frames while ssim and vmaf are better suited to a wider vantage point, especially if motion is involved.