fix(hdr): latch HDR colorspace so a transient SDR reinit can't downgrade the stream#283
Open
sh00bx wants to merge 1 commit into
Open
fix(hdr): latch HDR colorspace so a transient SDR reinit can't downgrade the stream#283sh00bx wants to merge 1 commit into
sh00bx wants to merge 1 commit into
Conversation
…ade the stream
A virtual display created for an HDR session briefly re-enumerates as SDR
during a capture reinit (the double-refresh / HDR-profile mode change ~1s into
a session momentarily drops the output to G22 8-bit). make_encode_device
re-reads is_hdr() on every reinit, so the encoder was rebuilt for an 8-bit SDR
colorspace mid-session and streamed SDR frames to an HDR client, which faults
the client decoder ("decoder reported error") and tears the session down.
Latch the established-HDR state per session (a field on sync_session_ctx_t for
sync capture, a local in the async capture loop) so that once an HDR-requested
session has actually established HDR, a momentary is_hdr()==false during a
reinit can no longer downgrade the wire colorspace. Genuinely-SDR sources never
latch because hdr_display is never true for them.
The legacy dd_wa_hdr_toggle workaround that previously masked this was removed
in the v1.14 display refactor; this covers the capture-side path that the
display-device config-apply does not.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A virtual display created for an HDR session briefly re-enumerates as SDR during a capture reinit — the double-refresh / HDR-profile mode change ~1s into a session momentarily drops the output to G22 8-bit.
make_encode_devicere-readsis_hdr()on every reinit, so the encoder was rebuilt for an 8-bit SDR colorspace mid-session and streamed SDR frames to an HDR client. That faults the client decoder ("decoder reported error") and tears the session down.The legacy
dd_wa_hdr_toggleworkaround that previously masked this was removed in the v1.14 display refactor; this covers the capture-side path that the display-device config-apply does not.Fix
Latch the established-HDR state per session (a field on
sync_session_ctx_tfor sync capture, a local in the async capture loop) so that once an HDR-requested session has actually established HDR, a momentaryis_hdr() == falseduring a reinit can no longer downgrade the wire colorspace. Genuinely-SDR sources never latch becausehdr_displayis never true for them.Single-file change in
src/video.cpp(+29/-3).🤖 Generated with Claude Code