Ran into this while trying to figure out why my screenshare looked choppy to people while I was playing Deadlock. Poked around Settings > Video and found something weird.
My rig is a Ryzen 7 7800X3D + RTX 5070 on Windows 11. The 7800X3D has that tiny built-in Radeon iGPU like every AM5 chip does, but my display and games all run off the 5070.
Under Hardware Acceleration, AV1 was set to NVENC/CUVID like I’d expect. But H264 encoding defaulted to “AMD AMF H.264 Encoder” and decoding to “H264 AMD AMF video decoder”. I never touched those - that’s just how the client set them up. The thing is, AMF only has that dead 2-CU integrated Radeon to run on (Windows even reports it as off-line), while NVENC H264 on the actual 5070 is right there in the dropdown, just not picked.
So for H264 the client went with the weakest option instead of the good one on the card that’s actually doing the work. AV1 got it right, H264 didn’t.
Why I think it matters: whenever H264 gets used (fallback for viewers who can’t decode AV1, etc.) it’s running on an iGPU that’s barely there or off completely. On machines where the iGPU is disabled in BIOS I’d guess it just fails outright. And Ryzen + Nvidia is a really common combo, so this probably hits a lot of people.
How to see it:
Any AM5 Ryzen chip (with the built-in Radeon) + an Nvidia card as the main GPU
Settings > Video > Hardware Acceleration > expand the per-codec backends
Look at what H264 encode/decode defaulted to
For me it was AMF on both, with NVENC/CUVID sitting available in the list.
Workaround is easy - just switch H264 encode to NVIDIA NVENC and decode to Nvidia CUVID by hand. But the default looks wrong to me.
AV1 picking Nvidia correctly, but H264 choosing AMD AMF instead, feels like the client might be choosing the first available H264 encoder instead of the more suitable/default GPU. The workaround is easy once you know where to look, but I doubt many users will ever check those advanced codec settings.
So I’d also say this is worth looking into, especially because Ryzen + Nvidia is a pretty common setup.
The client does capability checks at startup and tried to encode/decode frames in that process. That succeeded so it shows that.
In your case, it might still be preferable to use the ‘dead’ iGPU - hw encoders/decoders are most likely not processed by the compute units, but rather dedicated areas on the chip (i think the VCE).
So, doing it this way would even free up your main GPU a bit more (less memory bandwidth usage, uploads/downloads, encoder/decoder engines are separate on dedicated GPUs as well (in general), but still put thermal load on it) - which might be preferable as the default choice.
Of course, the quality difference of AMF vs NVENC is one big choice to keep in mind.
We will keep this in mind and discuss this internally. Thanks for the feedback!
I didn’t really think about the iGPU as a separate hardware encoder instead of just “unused graphics hardware”. From that point of view, I can understand why using AMF could be a reasonable default, especially if it keeps some load away from the main GPU while gaming.
The reason it felt odd from a user perspective is mostly the different behavior between AV1 and H264. AV1 picks Nvidia automatically, while H264 goes to AMD AMF, even though NVENC is also available. Without knowing the reasoning behind it, it looks like the client picked the wrong GPU.
Maybe it would help if the automatic choice was a bit clearer in the UI, or if there was a simple preference like “prefer dedicated GPU”, “prefer quality”, or “prefer lower main GPU load”.
But your explanation definitely makes the current behavior more understandable. Thanks for keeping it in mind and discussing it internally.
If AV1 doesn’t have a usable AMF option on that iGPU, then NVENC being selected there is logical. For H264, both AMF and NVENC are available, so it is more about the default priority than a detection issue.
From a user perspective it just looked a bit confusing at first, because AV1 picked Nvidia while H264 picked AMD.
