HDR Tone Mapping Issues on SDR Displays - Browser & Windows App

[denisj 2]

Hi everyone,

I've been running Emby Server on a Proxmox LXC with three NVIDIA RTX 3090 GPUs, and I wanted to share some issues I've encountered with HDR content playback and a few feature requests that I think would benefit the community.

---

**My setup:**
- Server: Proxmox LXC, 3x NVIDIA RTX 3090, Xeon Gold 6148
- Client: Windows 11 PC, Samsung SDR monitor (no HDR support)
- Emby Windows app: v2.310.2.0
- Content: HDR10 and Dolby Vision MKV files

---

**Issue 1: HDR content appears very dark in the browser**

When streaming HDR10 content via Chrome or Firefox, the image appears significantly darker compared to the same file played locally with VLC or mpv. After investigation, I discovered that even though the server is configured with hardware tone mapping (Hable algorithm), Emby is performing a remux instead of a full transcode — so the tone mapping pipeline is never actually applied. The browser receives raw HDR video and has no way to handle it correctly on an SDR display.

The dashboard confirms this: the session shows "Direct Play" or "Remux" for the video track, meaning the server-side tone mapping settings are completely bypassed.

There is currently no server-level option to force HDR transcoding for all clients. The only workaround is to manually lower the bitrate limit per user, which is not ideal and not persistent across devices.

**Feature request:** Add a server-level option to force transcoding (and apply tone mapping) when the source is HDR and the client does not report HDR display support.

---

**Issue 2: Emby Windows app does not allow custom MPV parameters**

The Emby Windows app (v2.310.2.0) uses libmpv internally for video playback, which is excellent. However, the app initializes MPV with `--no-config`, completely ignoring any external `mpv.conf` file — even one placed in the expected `%APPDATA%\mpv\` location.

I confirmed this by reading the MPV log files (accessible from the app's About page), which show no "Reading config file" line and confirm that all properties are set exclusively via code by the app.

The Customize mode in the app exposes some useful parameters (tone mapping algorithm, HDR contrast recovery, HDR peak computation), but critical parameters for SDR displays are missing:
- `target-peak` (nits of the display)
- `saturation` / `contrast` / `brightness` corrections
- `gamut-mapping-mode`
- `vf` (video filters)

For reference, the parameters that actually produce a good HDR→SDR result on my SDR display are:
```
tone-mapping=spline
target-peak=70
target-primaries=bt.709
target-trc=srgb
gamut-mapping-mode=perceptual
saturation=-59
contrast=-15
bright=4
```

Without access to these, the image on SDR displays is either too dark, oversaturated, or both — regardless of the tone mapping algorithm selected in the UI.

**Feature request:** Either expose these additional MPV parameters in the Customize UI, or allow loading a user-provided `mpv.conf` file from a configurable path.

I'm aware there is already a feature request open for this ("Add custom mpv.dll options / parameters to launch") — I'm adding my voice to support it.

---

**Issue 3: NVDEC decoder causes crashes with software encoder**

When running the built-in transcoding test, NVDEC as decoder consistently fails with "Object reference not set to an instance of an object" when paired with a software encoder, across all content types (H.265, HDR10, Dolby Vision). The same content works perfectly when using CUVID as the decoder instead.

NVDEC works correctly when paired with NVENC as the encoder, but since the app selects decoder/encoder combinations automatically in some scenarios, this can cause unexpected playback failures.

**Suggestion:** Consider adding a warning or automatically excluding NVDEC+Software combinations that are known to fail, or document this limitation more clearly.

---

**Issue 4: No way to force NFS over SMB for media mounts**

This is more of a documentation/guidance issue: when media is mounted via Samba/SMB, high-bitrate files (8-10GB MKV) can cause intermittent video freezes, audio/video desync, and seek instability during transcoding. The transcoding process writes temp files while simultaneously reading the source over the network, and SMB introduces enough latency to disrupt this.

Switching to NFS mount resolves the issue entirely, but there is no mention of this in the Emby documentation for Linux server setups.

**Suggestion:** Add a note in the server documentation recommending NFS over SMB for media storage when transcoding is enabled.

---

I hope this is useful for the team and for other users running similar setups. Happy to provide logs or additional details for any of the above.

Thanks for the great software — despite these issues, Emby has been a solid platform overall.

[denisj 2]

**UPDATE: Partial solution found for Issue #2 (custom MPV parameters)**

I wanted to follow up on my previous post, specifically regarding Issue #2 (Emby Windows app ignoring mpv.conf).

After further investigation, I found that there are actually **two different versions** of the Emby Windows client:

1. **Emby Windows (Microsoft Store)** — version 2.310.2.0, the modern WinUI3-based app
2. **Emby Theater** — the older Electron-based standalone app, available on GitHub at https://github.com/MediaBrowser/emby-theater-windows/releases

The Microsoft Store version (which I was using) initializes libmpv with `--no-config` and completely ignores any external `mpv.conf` file, as I described in my original post.

However, the **standalone Emby Theater (Electron version) does read `mpv.conf`** from the standard MPV location:
```
C:\Users\<username>\AppData\Roaming\mpv\mpv.conf
```

After switching to this version and adding my custom HDR tone mapping parameters to that file, everything works correctly. The image quality on my SDR monitor is now excellent, with proper HDR→SDR conversion.

For anyone with a similar setup (HDR content on an SDR display), here are the parameters I'm using:

```ini
# HDR→SDR tone mapping algorithm
tone-mapping=spline

# Dynamic HDR peak detection for more accurate tone mapping
hdr-compute-peak=yes

# Target display peak brightness in nits (adjust to match your monitor)
target-peak=72

# Target SDR color space
target-primaries=bt.709
target-trc=srgb

# Gamut mapping mode for BT.2020→BT.709 conversion
gamut-mapping-mode=perceptual

# Reduce oversaturation caused by the wider BT.2020 gamut
saturation=-62

# Reduce contrast to prevent blown highlights and crushed blacks
contrast=-16

# Compensate for brightness loss during HDR→SDR conversion
brightness=4
```

Note: do NOT include `hwdec`, `vo`, or `gpu-api` directives in the file — let Emby Theater manage those internally, otherwise you may get a black screen.

The issue with the Microsoft Store version still stands and I think it would be a great improvement to support custom mpv parameters there as well — but at least this is a working alternative for now.

Hope this helps someone!

Denis