Ultimate mpv.conf Guide (2026): HDR10+, Dolby Vision, gpu-next & Atmos Setup

Last verified: October 2026

The latest stable mpv release is 0.41. Current development builds contain additional work intended for mpv 0.42, including major Dolby Vision Profile 7 improvements. Where behavior differs between stable 0.41 and current development/0.42, this guide calls that out explicitly.

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.

The configuration below is primarily designed for Windows. Nvidia and Intel GPUs can generally use the same D3D11 architecture, while Linux requires platform-specific rendering, hardware decoding, audio, and HDR considerations covered briefly later in this guide.

TL;DR

– Modern mpv config using `gpu-next` + D3D11
– SDR desktop, HDR only when needed
– Smart handling of HDR10, HDR10+, Dolby Vision
– Native mpv handling of supported Dolby Vision metadata, with Profile 7 MEL and FEL processing available in current development builds intended for mpv 0.42+
– 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, and generic HDR, while letting current mpv decide when Dolby Vision metadata is actually usable.
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 config is centered around gpu-next, mpv’s modern libplacebo-based renderer. Since mpv 0.41, gpu-next is also the default renderer, so vo=gpu-next is no longer strictly required. I keep it explicit because it documents the intended rendering path and makes the configuration easier to understand.

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. For this deliberately D3D11-based Windows HTPC configuration, it provides a predictable native hardware-decoding path. It should be understood as a deliberate choice for this setup rather than a universal mpv default.

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 remains my preferred model for a mixed-use Windows HTPC: SDR stays SDR during normal desktop use, while HDR content enables an HDR-aware output path when playback begins. 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

auto is now mpv’s default, so this line is technically redundant. I keep it explicit because the HDR profiles below intentionally override it.

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 Dolby Vision still deserves its own profile

Dolby Vision is a special case because hdr-compute-peak=yes does not simply mean “ignore metadata and analyze the image instead.”

With gpu-next, enabling hdr-compute-peak makes libplacebo’s peak detector available, but usable Dolby Vision RPU metadata can still take precedence internally. This is why toggling computed peak detection on Dolby Vision does not behave the same way as it does on plain HDR10.

A dedicated Dolby Vision profile therefore still makes sense:

hdr-compute-peak=no

This setting does not enable RPU processing. mpv/libplacebo already consumes usable Dolby Vision metadata automatically. Instead, it makes the configuration policy explicit: for known Dolby Vision sources, trust the RPU metadata path rather than requesting generic image-derived peak detection as well.

That distinction also keeps the configuration easier to understand and troubleshoot. Generic HDR uses computed scene analysis; Dolby Vision uses its RPU-aware path.

Stable mpv 0.41 should remain conservative about Profile 7 because it predates the major 2026 Profile 7 work. Current development builds intended for mpv 0.42 add Profile 7 MEL support and full enhancement-layer processing for FEL sources.

The underlying behavior is confirmed by the still-open upstream issue specifically asking for hdr-compute-peak=yes to override Dolby Vision metadata. In August 2026, when somebody again asked how to force computed analysis instead of RPU, the mpv maintainer’s answer was still to strip Dolby Vision with vf=format=dolbyvision=no.

Why HDR10+ gets its own metadata profile

The HDR10+ profile sets:

tone-mapping=st2094-40
hdr-compute-peak=no

HDR10+ provides actual scene-level ST 2094-40 metadata, so this profile disables generic peak analysis and selects mpv’s dedicated HDR10+ tone-mapping path.

Keeping the profile after the generic HDR and Dolby Vision blocks ensures these conflicting mpv options take precedence when the HDR10+ condition matches.

That should not be confused with universally forcing HDR10+ metadata over Dolby Vision metadata inside libplacebo. libplacebo maintains its own metadata-source selection logic, which defaults to automatic selection.

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.

HDR subtitle brightness

Recent mpv versions also expose separate controls for subtitle brightness in HDR. If white subtitles are uncomfortably bright on an HDR display, sub-hdr-peak controls text/ASS subtitle and OSD diffuse white, while image-subs-hdr-peak controls bitmap subtitles such as PGS.

The current defaults are generally sensible, so I would not add either option to the base config unless you actually have a subtitle-brightness problem.

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
# =================================================================================================
#
# Last reviewed against upstream mpv: 2026-10-03
# 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

# 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.
# DISPLAY-SPECIFIC EXAMPLE VALUES
# These describe my intended display chain and should NOT be copied blindly.
# Leave them commented / automatic unless you know the measured capabilities of your display.
#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
# -------------------------------------------------------------------------------------------------

# Generic HDR fallback for plain HDR10 / HLG and other sources where a more
# specific metadata policy below does not apply.
#
# Profiles 5, 8 and 9 are excluded because they use the dedicated Dolby Vision
# RPU policy below. Profile 7 remains on this conservative fallback on stable
# mpv 0.41; see the 0.42+ note below.
[auto-hdr-generic]
profile-desc=Use computed scene analysis for generic HDR
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

# With no trusted dynamic-metadata path, analyze the image dynamically.
hdr-compute-peak=yes


# Dolby Vision Profiles 5, 8 and 9 use usable RPU metadata rather than the
# generic computed-peak policy.
[auto-dolby-vision-rpu]
profile-desc=Prefer Dolby Vision RPU metadata for profiles 5 8 and 9
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
hdr-compute-peak=no


# HDR10+ exposes real scene metadata through scene-max-r/g/b. Disable generic
# peak detection so the ST 2094-40 path can use that metadata.
[auto-hdr10plus]
profile-desc=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
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

Profile 7 on current development builds / mpv 0.42+

The base configuration above remains safe for stable mpv 0.41.

Current development builds intended for mpv 0.42 have substantially better Profile 7 handling, including MEL and FEL enhancement-layer processing. If you use one of those builds and want Profile 7 to follow the same explicit RPU policy as the other Dolby Vision profiles, add 7 to the Dolby Vision condition and exclude it from the generic HDR condition.

In other words, change the Dolby Vision condition to:

profile-cond=(get("current-tracks/video/dolby-vision-profile", 0) == 5) or (get("current-tracks/video/dolby-vision-profile", 0) == 7) or (get("current-tracks/video/dolby-vision-profile", 0) == 8) or (get("current-tracks/video/dolby-vision-profile", 0) == 9)

and add:

and (get("current-tracks/video/dolby-vision-profile", 0) ~= 7)

to [auto-hdr-generic].