If you have a high-end media PC, a modern OLED TV, and an AVR that can handle Atmos, it can be challenging to figure out the optimal setup for your mpv.conf to take advantage of all the hardware. I spent some time trying to figure this out, and hoping my notes can help you along the way. With mpv, there is no “one size fits all”, so expect to do a lot of testing until you find what works best on your particular system 🙂
The final configuration I came up with is designed for a modern Windows setup, gpu-next, D3D11 hardware decode, HDR-capable display, and an Atmos AVR audio chain. The goal is to use the current mpv renderer correctly, avoid redundant or counterproductive settings, and make the behavior predictable for SDR, HDR10, HDR10+, Dolby Vision-aware playback logic, and HDMI passthrough audio.
If your setup differs (Linux, Nvidia, or QLED displays), see the companion mpv setup guide addendum.
TL;DR
– Modern mpv config using `gpu-next` + D3D11
– SDR desktop, HDR only when needed
– Smart handling of HDR10, HDR10+, Dolby Vision
– Correct fallback for unsupported Dolby Vision profiles
– AVR-friendly passthrough audio (Atmos, DTS-HD)
Designed for high-end Windows HTPC systems.
Who this config is for
This is the best mpv config for high-end systems in 2026 if your setup looks something like this:
– modern Windows system
– strong GPU with stable D3D11 decode/rendering
– HDR-capable OLED or high-end HDR display
– AVR-based HDMI audio chain
– mixture of SDR, HDR10, HDR10+, and Dolby Vision-aware files
– preference for accurate, code-backed behavior instead of placebo tuning
Who should not use this exact config
If you are on a lower-end GPU, an unusual Linux compositor stack, a system where D3D11 is not relevant, or a playback path where passthrough audio is not important, you may want a different bias. This config is not trying to be universal. It is trying to be excellent for a specific class of premium media system.
Why this mpv config is the best choice for high-end systems in 2026
The strongest reason this config stands out is that it was validated against the current mpv manual and the mpv source tree, not just visual preference or inherited defaults. That matters because a lot of old mpv tuning advice no longer maps cleanly to gpu-next. In 2026, the quality ceiling for a high-end mpv setup comes less from forcing dozens of extra options and more from understanding what mpv already does by default, what should be explicit, and which choices belong in metadata-specific conditional profiles.
This config focuses on five things:
1. A modern Windows rendering path using gpu-next and D3D11.
2. A high-quality but sane scaling and dithering stack.
3. Correct SDR-first desktop behavior with HDR only when HDR content is present.
4. Metadata-aware handling for HDR10+, Dolby Vision profile 5, 8, and 9, plus sensible generic HDR fallback behavior for Dolby Vision profile 7 and unknown profiles.
5. Reliable HDMI passthrough for AVR-based audio systems, including Dolby Atmos carried over E-AC3 or TrueHD.
In other words, this is a quality-first config for systems that are already good enough to reveal bad assumptions.
The actual config philosophy
The biggest mistake people make with mpv configs is assuming that more options automatically means more quality. On current mpv builds, that is often false. Many of the options people still copy around are either already defaults, only useful on older renderer paths, or actively make the pipeline less coherent.
This configuration is built around a cleaner principle:
– be explicit where mpv benefits from clarity
– leave defaults alone where mpv already does the right thing
– use conditional profiles where the content type genuinely changes the optimal behavior
Note: mpv can ingest Dolby Vision and HDR10+ metadata internally, and it can use that information in meaningful ways, but it is not a native Dolby Vision output stack.
Why gpu-next is the right renderer in 2026
The entire config is centered around `vo=gpu-next` because gpu-next is the modern libplacebo-based renderer and the correct foundation for a high-end mpv setup in 2026. It gives you the most coherent HDR handling, better control over target/output behavior, modern tone-mapping paths, and better long-term alignment with how mpv is developed now.
Pairing that with `gpu-api=d3d11` and `gpu-context=d3d11` keeps the path native and direct on Windows. For this class of system, that is the right choice. It reduces avoidable translation layers and keeps the renderer aligned with Windows HDR behavior as mpv currently exposes it.
The hardware decode path is likewise straightforward: `hwdec=d3d11va`. On modern Windows hardware, this is the correct default for efficient decode without turning the config into a science project.
Why D3D11 zero-copy is enabled
`d3d11va-zero-copy=yes` is one of the few explicit performance-oriented choices in the config. It is not mandatory, and it can expose driver-specific edge cases on some systems, but on a stable high-end GPU stack it is a worthwhile optimization because it can remove an unnecessary GPU-side copy.
This option is intentionally treated as a quality-compatible efficiency choice rather than a magical image-quality enhancer. That is exactly the right way to think about it.
Why the swapchain is explicitly 10-bit
The config uses `d3d11-output-format=rgb10_a2`. That is a smart explicit choice for a serious HDR-capable chain because it ensures the swapchain can represent a 10-bit output path cleanly without forcing HDR globally at the desktop level.
That distinction matters. A lot of bad HDR configs confuse “use a 10-bit swapchain” with “force HDR metadata all the time.” Those are not the same thing, and collapsing them together is how people end up with poor SDR behavior on a desktop that should remain SDR unless HDR content is actually playing.
Why this config keeps an SDR-first desktop policy
One of the best design decisions in this config is that it does not force HDR behavior globally. Instead, the base profile leaves SDR desktop behavior intact and only enables HDR output policy when the source content is HDR.
That is the right model for a mixed-use Windows system. SDR content should remain SDR. HDR content should switch into HDR behavior when played. Trying to run the desktop as permanently HDR just to satisfy a media player is usually a compromise, not an upgrade.
This is why the base config uses:
target-colorspace-hint=auto
Then the `[HDR]` conditional profile enables HDR-oriented output policy only when the video transfer characteristics indicate PQ or HLG.
Why the scaling choices are high-end but still sane
For scaling, the config uses:
- `scale=ewa_lanczossharp`
- `cscale=ewa_lanczossharp`
- `dscale=mitchell`
- `scale-antiring=0.6`
- `cscale-antiring=0.6`
This is a practical high-end balance. It is sharp, well-established, and visually strong without drifting into overprocessing. `ewa_lanczossharp` remains a very good default for a powerful system, while `mitchell` for downscaling keeps the result controlled and natural.
Why the dithering stack is explicitly configured
The config sets:
- `dither-depth=10`
- `dither=error-diffusion`
- `error-diffusion=sierra-lite`
That is the correct quality-first posture for a 10-bit-capable chain. In gpu-next, dithering decisions are about the output depth after all rendering operations, not simply the original source bit depth. So even a 10-bit source can still benefit from correct dithering on the final write.
Why the audio section is right for a serious AVR setup
The audio section is built for a dedicated HDMI AVR chain:
- `ao=wasapi`
- `audio-exclusive=yes`
- `audio-channels=7.1,5.1,stereo`
- `audio-spdif=ac3,eac3,dts,dts-hd,truehd`
This is the correct Windows strategy for a setup where the AVR should do the heavy lifting for bitstream formats. It preserves passthrough for the formats that matter, including the E-AC3 and TrueHD containers that carry Atmos in normal home playback workflows.
That is also why the config does not try to use display-resample as a universal sync mode. In a passthrough-heavy AVR setup, that is not the right always-on default.
Why HDR handling needs separate logic for plain HDR, HDR10+, and Dolby Vision
The renderer needs a shared HDR policy, but it should not treat all HDR content identically. Plain HDR10, HDR10+, and Dolby Vision-aware files do not benefit from exactly the same strategy.
That is why the config uses a layered profile design:
- `[HDR]` for shared HDR output behavior
- `[auto-hdr-generic]` for generic HDR fallback analysis
- `[auto-dolby-vision-rpu]` for DV profile 5, 8, and 9
- `[auto-hdr10plus]` for real HDR10+ scene metadata
This is important because current mpv auto profile behavior can apply multiple matching profiles, and later applications can override conflicting options. The final design intentionally avoids conflict between the shared HDR block and the metadata-specific blocks.
Why generic HDR still uses compute-peak
For plain HDR10 or HLG without HDR10+ metadata and without Dolby Vision profiles that mpv should treat specially, the config uses `hdr-compute-peak=yes` in the generic fallback profile.
That is the right fallback for premium playback because when there is no trusted dynamic metadata path, per-scene analysis remains the best general-purpose answer. It is flexible, robust across mixed masters, and usually better than having all HDR driven by a single static mastering number.
This same generic fallback also handles Dolby Vision profile 7 and unknown Dolby Vision profiles when HDR10+ metadata is not present. That is exactly the right outcome on current mpv, where enhancement-layer playback is not supported.
Why Dolby Vision profile 5, 8, and 9 are treated differently
For Dolby Vision profile 5, 8, and 9, the config sets:
hdr-compute-peak=no
That is not because mpv is outputting native Dolby Vision. It is because current mpv can ingest Dolby Vision metadata internally and map useful HDR-related information from the Dolby Vision path. For these single-layer or streaming-style profile families, trusting the metadata path more than frame peak analysis is the most coherent strategy.
This keeps mpv from fighting the metadata with a separate compute-peak policy when the Dolby Vision path is already supplying useful dynamic information.
On the other hand, Dolby Vision profile 7 with enhancement layers is not a case where mpv can just do “full Dolby Vision.” The current code path explicitly warns that enhancement-layer playback is not supported. So, the correct strategy is to let profile 7 fall back to generic HDR handling.
Why HDR10+ gets the highest metadata priority
The HDR10+ profile is intentionally last among the metadata-specialized blocks and sets:
tone-mapping=st2094-40
hdr-compute-peak=no
This gives real HDR10+ scene metadata final priority for conflicting options. That is the right choice because mpv has a dedicated HDR10+ tone-mapping path for this case, and the detection is tied to actual HDR10+ scene metadata fields rather than a loose heuristic. If a file somehow exposes both HDR10+ scene metadata and Dolby Vision-compatible metadata, HDR10+ takes precedence for conflicting options in this config. That is intentional.
What `source-dynamic` really means and why it was chosen
One of the most misunderstood options in mpv HDR configs is:
target-colorspace-hint-mode=source-dynamic
This does not mean mpv is outputting native HDR10+ to the TV. It does not mean mpv is outputting Dolby Vision. What it does is use dynamic metadata information upstream to produce scene-varying HDR10-style luminance hints on output.
That makes it the most interesting choice for high-end systems that can actually benefit from more dynamic downstream HDR signaling, especially when the display stack reacts well to changing output metadata.
Final Thoughts
The best mpv config in 2026 is not the one with the most settings.
It is the one that:
– aligns with current mpv behavior
– respects hardware limits
– uses metadata correctly
– avoids unnecessary overrides
This configuration is built around those principles. See below:
# =================================================================================================
# MPV Configuration for Jellyfin MPV Shim
# =================================================================================================
#
# Publication version: 2026-03-18
# Intended audience: high-end Windows home theater systems
#
# Design goals for this profile:
# - preserve SDR-for-SDR and HDR-for-HDR desktop behavior on Windows
# - keep audio behavior friendly to a dedicated AVR chain
# - align the renderer and HDR logic with current mpv and gpu-next behavior
# - avoid stale, redundant, or counterproductive options
# -------------------------------------------------------------------------------------------------
# Video Renderer and Decode Path
# -------------------------------------------------------------------------------------------------
# gpu-next is mpv's modern libplacebo-based renderer and the right foundation
# for a quality-focused 2026 configuration.
vo=gpu-next
# Native D3D11 keeps the Windows path direct and avoids unnecessary translation
# layers in the render stack.
gpu-api=d3d11
gpu-context=d3d11
# D3D11VA is the correct native hardware decode path for this class of Windows
# system and keeps decode aligned with the rest of the renderer path.
hwdec=d3d11va
# Zero-copy can remove an extra GPU-side copy on stable drivers. It is kept
# enabled here because the target system is strong enough to benefit from the
# cleaner path, while still being easy to disable if a specific driver stack
# shows sampling or compatibility issues.
d3d11va-zero-copy=yes
# Use an explicit 10-bit swapchain format without forcing HDR globally. The
# point is to keep output precision high while preserving an SDR desktop unless
# HDR content actually requires HDR signaling.
d3d11-output-format=rgb10_a2
# -------------------------------------------------------------------------------------------------
# Audio Path for HDMI AVR Playback
# -------------------------------------------------------------------------------------------------
# WASAPI exclusive is the correct Windows output path when the AVR should own
# final format handling and passthrough behavior.
ao=wasapi
audio-exclusive=yes
# Restrict PCM negotiation to sensible HDMI AVR layouts instead of allowing
# mpv to wander into channel configurations that do not help this setup.
audio-channels=7.1,5.1,stereo
# Allow passthrough for the formats that matter in a home theater chain,
# including the E-AC3 and TrueHD containers that commonly carry Atmos.
audio-spdif=ac3,eac3,dts,dts-hd,truehd
# -------------------------------------------------------------------------------------------------
# Video Timing and Presentation
# -------------------------------------------------------------------------------------------------
# Keep the sync model simple and AVR-safe. In current mpv code, the
# display-resample path explicitly returns early when SPDIF passthrough is
# active, so it is not a good global default for a passthrough-heavy setup.
#
# This also fits current Windows VRR reality. mpv's D3D11 path still presents
# through the normal DXGI model, so any VRR cooperation is ultimately handled
# by the driver and OS rather than a special mpv-only sync mode.
video-sync=audio
# -------------------------------------------------------------------------------------------------
# Dithering and Internal Precision
# -------------------------------------------------------------------------------------------------
# Be explicit about a 10-bit output target. In gpu-next, dithering is tied to
# the output depth after rendering, not just the source file depth, so even a
# 10-bit source can still benefit on the final write to the swapchain.
dither-depth=10
# Error diffusion costs more GPU work, but that tradeoff is justified here
# because the entire profile is tuned for output quality over minimum load.
#
# Kernel notes:
# - sierra-lite: mpv's documented default; fastest reasonable choice
# - floyd-steinberg: classic reference kernel
# - burkes: stronger quality/performance tradeoff than sierra-lite, but heavier
# - atkinson: different look, sometimes useful for screenshots or personal taste
#
# Larger kernels exist, but mpv's own documentation warns that many of them are
# disproportionately slower and heavier on shared memory. If future A/B testing
# is desired, floyd-steinberg and burkes are the most sensible alternatives.
dither=error-diffusion
error-diffusion=sierra-lite
# -------------------------------------------------------------------------------------------------
# Scaling Quality
# -------------------------------------------------------------------------------------------------
# These are strong, proven quality settings that still make sense for a modern
# high-end integrated GPU
scale=ewa_lanczossharp
cscale=ewa_lanczossharp
dscale=mitchell
scale-antiring=0.6
cscale-antiring=0.6
# Sigmoid upscaling is already enabled by default in current builds, so forcing
# it here would only add noise to the file without changing behavior.
# -------------------------------------------------------------------------------------------------
# Default Desktop Policy: SDR Stays SDR
# -------------------------------------------------------------------------------------------------
# Keep the desktop policy SDR by default. On the current D3D11 gpu-next path,
# auto mode can provide sane SDR output metadata without forcing HDR behavior
# for everyday desktop use.
target-colorspace-hint=auto
# Leave SDR target parameters automatic in the base profile. For SDR material,
# gpu-next already does the right thing, while the HDR profile below takes over
# when explicit HDR output policy is actually needed.
# Debanding is a practical quality win on both SDR and HDR and is worth keeping
# enabled in a quality-first profile.
deband=yes
# -------------------------------------------------------------------------------------------------
# HDR Base Profile: HDR Enables HDR
# -------------------------------------------------------------------------------------------------
# This block handles the shared HDR output policy for PQ and HLG sources. The
# condition syntax is current mpv auto_profiles syntax, not an old legacy form.
[HDR]
profile-desc=Enable HDR output policy for PQ or HLG sources
profile-cond=p["video-params/gamma"] == "pq" or p["video-params/gamma"] == "hlg"
profile-restore=copy
# When the source is HDR, allow mpv to switch the output path into HDR-aware
# signaling instead of leaving the swapchain in a generic SDR state.
target-colorspace-hint=yes
# source-dynamic tells gpu-next to build output hints from source metadata and,
# when dynamic metadata exists, turn it into scene-varying HDR10-style luminance
# hints. This does not output native Dolby Vision or HDR10+, but it is the most
# useful experimental mode for a high-end Windows HDR chain that responds well
# to scene-varying HDR10-style output hints.
target-colorspace-hint-mode=source-dynamic
# Describe the intended HDR output target for this display chain. The panel is
# treated as PQ / BT.2020 container / P3-limited gamut with a practical 800 nit
# peak target rather than an unrealistic paper spec.
target-trc=pq
target-prim=bt.2020
target-gamut=dci-p3
target-peak=800
target-contrast=inf
# Keep the shared HDR behavior here and push metadata-specific decisions into
# the conditional profiles below. That separation prevents later profile
# application from accidentally undoing format-specific choices.
gamut-mapping-mode=perceptual
hdr-peak-percentile=99.995
hdr-contrast-recovery=0.30
# -------------------------------------------------------------------------------------------------
# HDR Metadata Precedence
# -------------------------------------------------------------------------------------------------
# This is the generic HDR fallback. It covers plain HDR10 or HLG, Dolby Vision
# profile 7 fallback, and unknown Dolby Vision profiles whenever HDR10+ scene
# metadata is not present.
[auto-hdr-generic]
profile-desc=Use computed scene analysis for HDR without HDR10+ and without supported DV metadata-specialized profiles
profile-cond=(p["video-params/gamma"] == "pq" or p["video-params/gamma"] == "hlg") and (get("video-params/scene-max-r", 0) <= 0) and (get("video-params/scene-max-g", 0) <= 0) and (get("video-params/scene-max-b", 0) <= 0) and (get("current-tracks/video/dolby-vision-profile", 0) ~= 5) and (get("current-tracks/video/dolby-vision-profile", 0) ~= 8) and (get("current-tracks/video/dolby-vision-profile", 0) ~= 9)
profile-restore=copy
# When there is no metadata-specific path worth trusting, computed peak analysis
# remains the most robust general-purpose HDR fallback.
hdr-compute-peak=yes
# For streaming-style single-layer Dolby Vision profiles, trust the Dolby
# Vision metadata path more than generic frame analysis. This block appears
# after the generic fallback so supported DV profiles override it cleanly.
[auto-dolby-vision-rpu]
profile-desc=Prefer Dolby Vision metadata path for profile 5 8 and 9 content
profile-cond=(get("current-tracks/video/dolby-vision-profile", 0) == 5) or (get("current-tracks/video/dolby-vision-profile", 0) == 8) or (get("current-tracks/video/dolby-vision-profile", 0) == 9)
profile-restore=copy
# Disable compute-peak here so mpv does not fight the DV-derived metadata path
# with a second, less specific scene-analysis policy.
hdr-compute-peak=no
# If HDR10+ scene metadata exists, prefer mpv's dedicated HDR10+ path. This is
# intentionally the last metadata-specialized block so HDR10+ wins if a file
# ever exposes both HDR10+ and Dolby Vision-compatible metadata.
[auto-hdr10plus]
profile-desc=Automatically prefer HDR10+ metadata when present
profile-cond=(get("video-params/scene-max-r", 0) > 0) or (get("video-params/scene-max-g", 0) > 0) or (get("video-params/scene-max-b", 0) > 0)
profile-restore=copy
# Use the HDR10+ tone-mapping path directly and avoid redundant compute-peak
# analysis when real HDR10+ scene metadata is available.
tone-mapping=st2094-40
hdr-compute-peak=no
# -------------------------------------------------------------------------------------------------
# Jellyfin MPV Shim Behavior
# -------------------------------------------------------------------------------------------------
# Keep file-to-file behavior predictable inside Jellyfin MPV Shim and disable
# extra on-screen UI components that are unnecessary in a dedicated front-end.
reset-on-next-file=all
fullscreen=yes
osd-bar=no
Pingback: mpv HDR Guide 2026: HDR10, HDR10+, Dolby Vision & Tone Mapping Explained - Carlos Felicio
Pingback: mpv Setup Guide 2026 (Addendum): Linux, Nvidia, Intel & QLED Differences - Carlos Felicio