feat(linux/pipewire): Handle HDR(Rec. 2020/SMPTE 2084 PQ) visuals#5025
feat(linux/pipewire): Handle HDR(Rec. 2020/SMPTE 2084 PQ) visuals#5025garnacho wants to merge 1 commit intoLizardByte:masterfrom
Conversation
Bundle ReportBundle size has no change ✅ |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5025 +/- ##
==========================================
- Coverage 17.98% 17.33% -0.66%
==========================================
Files 109 108 -1
Lines 23502 23248 -254
Branches 10373 10141 -232
==========================================
- Hits 4228 4029 -199
+ Misses 17757 15733 -2024
- Partials 1517 3486 +1969
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 65 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
- Changed handling order of supported formats in DMA-buf cases, so the preferred format is predictable. - Dropped the last "guard" value from the format_map array, unused. - Added fallback value for SPA_VIDEO_TRANSFER_SMPTE2084, new in Pipewire >= 1.6.0 libraries. This format can be negotiated regardless. - Added support for 10-bit format, combined with BT.2020 color primaries and PQ transfer function. This format is preferred over SDR if supported by the compositor. - Tested over GNOME Shell 50, capable of HDR streaming. Should work over recent KDE Plasma as well.
|
|
I don't have a real HDR-capable client to test fully, but GNOME did seem to stream HDR with the same washed-out colours as kmsgrab. KDE doesn't work with HDR, but I don't think it's your fault. Full KDE log in case it helps: https://gist.github.com/psyke83/02c501dbfc4f3b157196cd0aa5a928ae Edit: previously I misidentified some errors in my log that were not actually related to this PR, please disregard. |
|
Ah indeed, I had the impression KDE also had HDR streaming support merged, these logs: Suggest that BGRA format was chosen (i.e. no 10-bit color), and KDE did not fill in (yet) color primaries and transfer function metadata. |
Don't have a HDR capable display here atm either but it would be great to have this in Sunshine as it might just provide the necessary test application that Xaver Hugl is looking for in https://invent.kde.org/plasma/kwin/-/merge_requests/8293#note_1471304 (Cite: ... So there isn't actually any test app that clearly verifies it works). I've noticed the code comments on missing HDR metadata in the commit and if I'm guessing correctly that should be covered by https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5064 once that's available. |
|
Just to clarify my earlier comment: I don't think we need to wait for KDE support; I was just pointing out that it's not ready on their side. The PR looks fine to me right now, seems to work on GNOME with the limited testing I can do, and if having this ready in Sunshine helps accelerate KDE merging 10 bit & HDR screencasting, all the better. |
That indeed would help drop most of the guesswork. A thing I am unclear though is about who and where in the pipeline things are converted to the capabilities of the target display on the other end. |
4 participants
Description
Support HDR streaming (10-bit + Rec. 2020 + SMPTE 2084 thus far, other combinations might be allowed later on) in the pipewire implementation.
Screenshot
Issues Fixed or Closed
Roadmap Issues
Type of Change
Checklist
AI Usage