mpv Setup Guide 2026 (Addendum): Linux, Nvidia, Intel & QLED Differences

This mpv setup guide 2026 addendum expands on the baseline configuration from the main guide.

If you haven’t read the core setup yet, start with the main Best mpv config 2026, which defines the reference Windows + gpu-next configuration used here.

This article focuses on what changes when:

• you switch GPU vendors (Nvidia, Intel)
• you move to Linux
• you use different display types like QLED instead of OLED

The goal is not to replace the baseline, but to explain how to adapt it safely.

This addendum assumes the current baseline remains the reference setup:

• Windows
• mpv with vo=gpu-next
• gpu-api=d3d11
• gpu-context=d3d11
• hwdec=d3d11va
• AVR audio over HDMI with ao=wasapi
• passthrough formats enabled with audio-spdif=ac3,eac3,dts,dts-hd,truehd
• OLED-class HDR display behavior as the starting point

The short answer is that the current setup remains a strong starting point across more hardware than just Radeon. The bigger differences come from platform and display behavior, not from the GPU vendor alone.

Baseline rule

For modern Windows systems, the current setup is still the right default starting point for AMD, Nvidia, and Intel unless you hit a real driver-specific problem.

That means:

• keep vo=gpu-next
• keep the native Windows D3D11 render path
• keep hwdec=d3d11va first
• keep WASAPI exclusive mode if the AVR is the destination
• keep the current HDR profile logic unless the display behavior itself is different enough to justify tuning

In other words, do not assume you need a different architecture just because the GPU vendor changes.

Nvidia on Windows

For Nvidia on Windows, I would still start with the same high-level design:

vo=gpu-next
gpu-api=d3d11
gpu-context=d3d11
hwdec=d3d11va
ao=wasapi
audio-exclusive=yes
audio-spdif=ac3,eac3,dts,dts-hd,truehd

What stays the same

• gpu-next is still the right renderer.
• D3D11 is still the right native Windows graphics path.
• WASAPI exclusive mode is still the right AVR-oriented audio path.
• HDR10, HDR10+, Dolby Vision-aware fallback logic, and Atmos-over-E-AC3/TrueHD logic still make sense.

What I would watch on Nvidia

• d3d11va-zero-copy=yes is still worth testing, but Nvidia can be more sensitive to driver-specific presentation or sampling issues on some systems. If you see weirdness, disable zero-copy first before changing larger parts of the stack.
• I would not jump to CUDA or older Nvidia-specific decode paths just because the GPU is Nvidia. On Windows, d3d11va keeps the decode path aligned with the renderer and is usually the better starting point.
• If HDR behavior is inconsistent, I would blame the Windows HDR chain, the TV, or the driver version before blaming the overall config design.

Bottom line for Nvidia on Windows

Very little needs to change. The same config philosophy still applies.

Intel on Windows

Intel on Windows is similar to Nvidia in one important way: the same render architecture still makes sense.

vo=gpu-next
gpu-api=d3d11
gpu-context=d3d11
hwdec=d3d11va

What stays the same

• gpu-next remains the correct renderer.
• D3D11 remains the correct Windows graphics path.
• d3d11va remains the right first-choice decode path.
• The AVR audio section does not need to change just because the GPU is Intel.

What I would watch on Intel

• On some iGPU-heavy systems, d3d11va-zero-copy=yes can be the first thing to disable if you see odd rendering or decode behavior.
• If the system is a lower-power mini PC rather than a stronger Arc or high-end Xe machine, I would be more willing to simplify the scaling stack before touching the core renderer design.
• Intel HDR behavior can be more sensitive to display firmware, Windows HDR state, and driver maturity than the config itself.

Bottom line for Intel on Windows

The current setup is still a good fit. The only likely changes are defensive ones around zero-copy or performance headroom, not a full redesign.

Linux changes more than vendor choice does

Linux is where I would stop saying “mostly keep it the same” and start saying “keep the philosophy, change the platform details.”

The right Linux config is much less universal because the compositor, session type, HDR support status, audio server, and GPU driver model all matter more directly.

What stays the same on Linux

• vo=gpu-next still remains the right renderer.
• A quality-first profile structure for SDR, HDR, HDR10+, and Dolby Vision-aware fallback logic still makes sense.
• If the system feeds an AVR, passthrough still matters.
• Direct-file playback still beats server-side transcode behavior.

What does not carry over from Windows

• Do not copy the D3D11 lines.
• Do not copy WASAPI.
• Do not assume Windows HDR desktop behavior maps directly to Wayland or X11.
• Do not assume HDR output support is equally mature across Linux desktops.

Linux on AMD

For AMD on Linux, I would start with Vulkan and VA-API:

vo=gpu-next
gpu-api=vulkan
hwdec=vaapi

Then pick the context based on the desktop session:

• gpu-context=waylandvk for Wayland when the stack is stable
• gpu-context=x11vk for X11 when that path is more reliable on the specific machine

Audio on Linux AMD

Audio depends more on the Linux audio stack than the GPU:

• ao=pipewire is the first place I would look on modern desktop Linux
• ao=pulse can still be fine where PipeWire is exposed through Pulse compatibility
• ao=alsa is more specialized and less convenient, but sometimes useful for focused HTPC builds

HDR on Linux AMD

This is the biggest caveat. Linux HDR behavior depends heavily on the compositor and current HDR support maturity. The mpv config can be correct and the platform can still be the limiting factor.

Linux on Intel

Intel on Linux is close to AMD in structure:

vo=gpu-next
gpu-api=vulkan
hwdec=vaapi

What I would watch on Intel Linux

• Wayland support may be good, but HDR behavior is still a platform question, not just an mpv question.
• On smaller Intel systems, performance headroom may matter more than on larger desktop GPUs.
• If the system struggles, I would simplify the scaling and rendering extras before abandoning the overall design.

Linux on Nvidia

Nvidia on Linux is the case where I would expect the most platform-specific testing.

I would still keep vo=gpu-next, but the rest becomes more conditional:

vo=gpu-next
gpu-api=vulkan
hwdec=nvdec

What I would watch on Nvidia Linux

• Compositor behavior matters a lot.
• HDR support maturity matters a lot.
• Driver behavior matters more than on the Windows D3D11 path.
• I would treat Nvidia Linux HDR as a platform-validation project, not as a simple transplant of the Windows config.

Bottom line for Linux

The same philosophy still applies, but Linux needs a Linux-native config rather than a literal copy of the Windows one.

QLED versus OLED

QLED changes less about the transport path and more about the display assumptions.

The audio section does not care whether the panel is OLED or QLED. The direct-path logic does not care either. The renderer still cares about HDR, but the target display behavior may differ enough that you should revisit the HDR tuning values.

What stays the same on QLED

• gpu-next still makes sense.
• D3D11 still makes sense on Windows.
• AVR audio and passthrough behavior remain the same.
• HDR10+ support remains especially relevant.
• Dolby Vision-aware fallback logic still matters because mpv is still not a native Dolby Vision output engine.

What I would revisit on QLED

1. HDR target assumptions

On a brighter QLED or mini-LED display, the OLED-biased assumptions around highlight behavior may no longer be ideal. I would revisit:

• target peak assumptions
• whether the current HDR target description matches the display
• whether hdr-contrast-recovery still looks right
• whether hdr-peak-percentile should stay exactly where it is

The baseline logic still makes sense, but the exact values may not be optimal.

2. Metadata handling preference

target-colorspace-hint-mode=source-dynamic can still be a strong choice on QLED, but some displays react better to one metadata strategy than another. On a QLED, I would be more willing to compare source-dynamic against target if the TV behaves strangely with dynamic signaling.

3. Dolby Vision expectations on Samsung-class QLED

If the QLED is a Samsung set, HDR10 and HDR10+ matter more than Dolby Vision in practical output terms. That does not make the mpv Dolby Vision-aware logic useless. It just means the fallback chain matters more than any fantasy of native Dolby Vision output.

QLED bottom line

QLED does not require a different playback architecture. It mainly requires re-checking HDR tuning against the actual display rather than assuming OLED-like behavior.

What I would change by category

If you switch from Radeon to Nvidia on Windows

• keep the same architecture
• keep d3d11va first
• test d3d11va-zero-copy=yes, disable it first if you hit driver weirdness

If you switch from Radeon to Intel on Windows

• keep the same architecture
• keep d3d11va
• be more ready to disable zero-copy on weaker or fussier iGPU systems
• simplify scaling only if performance actually demands it

If you switch from Windows to Linux

• keep gpu-next
• replace D3D11 with Vulkan-based contexts
• replace d3d11va with vaapi on AMD/Intel or nvdec on Nvidia
• replace WASAPI with PipeWire, PulseAudio, or ALSA depending the machine
• re-validate HDR behavior on the actual compositor stack

If you switch from OLED to QLED

• keep the transport path and audio path
• keep the HDR profile structure
• retune HDR target assumptions for the display
• test whether the current dynamic metadata hint mode still behaves best on that panel

Final conclusion

The current setup is not “Radeon-only.” It is best understood as a high-end Windows baseline that also fits Nvidia and Intel surprisingly well.

What changes most is not AMD versus Nvidia versus Intel. What changes most is Windows versus Linux, and OLED versus QLED.

So the practical summary is:

• Windows plus Radeon, Nvidia, or Intel: mostly the same setup, with minor decode or zero-copy adjustments if needed
• Linux: keep the philosophy, rewrite the platform-specific parts
• QLED: keep the architecture, revisit HDR tuning against the actual display

That is the cleanest way to generalize this setup without pretending one literal config file is optimal for every machine.