[PR #469] fix(hdr): complete end-to-end HDR transport #484

New issue

Open

opened 2026-10-15 13:00:55 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 13:00:55 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/wolf/pull/469
Author: @elibosley
Created: 7/31/2026
Status: 🔄 Open

Base: feat/vulkan-image ← Head: codex/hdr-vulkan-transport

📝 Commits (1)

886ef7e fix(hdr): stabilize Vulkan HDR transport

📊 Changes

18 files changed (+246 additions, -103 deletions)

View changed files

📝 src/moonlight-protocol/moonlight.cpp (+4 -1)
📝 src/moonlight-protocol/moonlight/control.hpp (+7 -1)
📝 src/moonlight-server/control/control.cpp (+24 -15)
📝 src/moonlight-server/events/events.hpp (+2 -13)
📝 src/moonlight-server/rest/endpoints.hpp (+2 -2)
📝 src/moonlight-server/rtsp/commands.hpp (+22 -2)
📝 src/moonlight-server/sessions/lobbies.cpp (+1 -0)
📝 src/moonlight-server/sessions/moonlight.cpp (+1 -0)
📝 src/moonlight-server/state/config.hpp (+19 -1)
📝 src/moonlight-server/state/configTOML.cpp (+16 -5)
📝 src/moonlight-server/state/data-structures.hpp (+3 -4)
📝 src/moonlight-server/state/serialised_config.hpp (+2 -1)
📝 src/moonlight-server/streaming/streaming.cpp (+44 -50)
📝 src/moonlight-server/streaming/streaming.hpp (+6 -2)
📝 tests/assets/config.test.toml (+1 -0)
📝 tests/testControl.cpp (+13 -1)
📝 tests/testMoonlight.cpp (+62 -0)
📝 tests/testRTSP.cpp (+17 -5)

📄 Description

Summary

This completes Wolf's end-to-end HDR transport path: capability advertisement, Moonlight negotiation, control-channel activation, producer configuration, 10-bit encoder selection, and per-frame color handling.

Root cause

Wolf previously mixed the connection-level HDR transport contract with the producer's frame-level SDR/PQ state. That allowed producer transitions to toggle Moonlight HDR mode after connection, while clients requesting HDR through dynamicRangeMode=1 could retain a stale SDR encoderCscMode. AV1 Main10 was also omitted from host capability advertisement, and hardware HDR capability was not constrained by the applications currently exposed to Moonlight.

Fix

Treat dynamicRangeMode as the authoritative HDR request and normalize HDR sessions to BT.2020/PQ.
Keep the negotiated Moonlight HDR transport stable for the connection lifetime.
Preserve per-frame SDR conversion and native PQ handling inside the GStreamer pipeline without renegotiating the client transport.
Send and replay the Moonlight HDR mode packet for the negotiated video session.
Advertise AV1 Main10 when AV1 and HDR are both supported.
Promote HDR VulkanImage and DMA-BUF producer caps to P010 and select Main10 encoder profiles.
Add per-app support_hdr configuration and advertise host HDR only when both the encoder and a currently exposed application support it.
Honor application-specific producer caps.
Use the standard GStreamer app-header include layout required by the Vulkan build.

Result

HDR-capable applications negotiate stable HEVC Main10 or AV1 Main10 BT.2020/PQ streams. SDR-only applications are not advertised as HDR-capable, while SDR frames presented during an HDR session are converted by the media pipeline without changing the negotiated transport.

Validation

Linux production target built against GStreamer 1.28.4 with the Vulkan encoder path enabled.
HDR and AV1 transport: 18 assertions.
RTSP negotiation: 144 assertions.
Application and capability state: 49 assertions.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/wolf/pull/469 **Author:** [@elibosley](https://github.com/elibosley) **Created:** 7/31/2026 **Status:** 🔄 Open **Base:** `feat/vulkan-image` ← **Head:** `codex/hdr-vulkan-transport` --- ### 📝 Commits (1) - [`886ef7e`](https://github.com/games-on-whales/wolf/commit/886ef7eaf2994b5ea34c8ea0845dfffecd41ebc6) fix(hdr): stabilize Vulkan HDR transport ### 📊 Changes **18 files changed** (+246 additions, -103 deletions) <details> <summary>View changed files</summary> 📝 `src/moonlight-protocol/moonlight.cpp` (+4 -1) 📝 `src/moonlight-protocol/moonlight/control.hpp` (+7 -1) 📝 `src/moonlight-server/control/control.cpp` (+24 -15) 📝 `src/moonlight-server/events/events.hpp` (+2 -13) 📝 `src/moonlight-server/rest/endpoints.hpp` (+2 -2) 📝 `src/moonlight-server/rtsp/commands.hpp` (+22 -2) 📝 `src/moonlight-server/sessions/lobbies.cpp` (+1 -0) 📝 `src/moonlight-server/sessions/moonlight.cpp` (+1 -0) 📝 `src/moonlight-server/state/config.hpp` (+19 -1) 📝 `src/moonlight-server/state/configTOML.cpp` (+16 -5) 📝 `src/moonlight-server/state/data-structures.hpp` (+3 -4) 📝 `src/moonlight-server/state/serialised_config.hpp` (+2 -1) 📝 `src/moonlight-server/streaming/streaming.cpp` (+44 -50) 📝 `src/moonlight-server/streaming/streaming.hpp` (+6 -2) 📝 `tests/assets/config.test.toml` (+1 -0) 📝 `tests/testControl.cpp` (+13 -1) 📝 `tests/testMoonlight.cpp` (+62 -0) 📝 `tests/testRTSP.cpp` (+17 -5) </details> ### 📄 Description ## Summary This completes Wolf's end-to-end HDR transport path: capability advertisement, Moonlight negotiation, control-channel activation, producer configuration, 10-bit encoder selection, and per-frame color handling. ## Root cause Wolf previously mixed the connection-level HDR transport contract with the producer's frame-level SDR/PQ state. That allowed producer transitions to toggle Moonlight HDR mode after connection, while clients requesting HDR through `dynamicRangeMode=1` could retain a stale SDR `encoderCscMode`. AV1 Main10 was also omitted from host capability advertisement, and hardware HDR capability was not constrained by the applications currently exposed to Moonlight. ## Fix - Treat `dynamicRangeMode` as the authoritative HDR request and normalize HDR sessions to BT.2020/PQ. - Keep the negotiated Moonlight HDR transport stable for the connection lifetime. - Preserve per-frame SDR conversion and native PQ handling inside the GStreamer pipeline without renegotiating the client transport. - Send and replay the Moonlight HDR mode packet for the negotiated video session. - Advertise AV1 Main10 when AV1 and HDR are both supported. - Promote HDR VulkanImage and DMA-BUF producer caps to P010 and select Main10 encoder profiles. - Add per-app `support_hdr` configuration and advertise host HDR only when both the encoder and a currently exposed application support it. - Honor application-specific producer caps. - Use the standard GStreamer app-header include layout required by the Vulkan build. ## Result HDR-capable applications negotiate stable HEVC Main10 or AV1 Main10 BT.2020/PQ streams. SDR-only applications are not advertised as HDR-capable, while SDR frames presented during an HDR session are converted by the media pipeline without changing the negotiated transport. ## Validation - Linux production target built against GStreamer 1.28.4 with the Vulkan encoder path enabled. - HDR and AV1 transport: 18 assertions. - RTSP negotiation: 144 assertions. - Application and capability state: 49 assertions. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-15 13:00:55 +00:00