Revert "linux-pipewire: Fix 10- and 16-bit captures"

[tytan652]

Description

Fixes #12412

This reverts commit 4dfd0b3.

Also adds a FIXME comment.

Motivation and Context

#11207 generated issues on SDR users.
And the PR itself tries to handle color space the wrong way, the portal implementation should provide a node with PipeWire colorimetry info in its formats for OBS Studio to handle textures correctly.

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[PancakeTAS]

Merging this would break capturing normal SDR 10-bit and 16-bit with pipewire. Why should this be merged?

[tytan652]

Merging this would break capturing normal SDR 10-bit and 16-bit with pipewire. Why should this be merged?

#11207 has secondary effect that are considered regressions in 31.1. Unfortunately, I don't think easily fixing with a few lines of code is possible. So revert has to be considered.

[PancakeTAS]

Unfortunately, I don't think easily fixing with a few lines of code is possible.

I disagree. Take a look at video_colorspace_from_spa_color_matrix in line 602 of pipewire.c. This hardcodes all supported color spaces to these few, likely because the original pipewire code does not support any other to begin with (though I couldn't find the source code responsible for this).

Next, take a look at formats.c, the method obs_pw_video_format_from_spa_format here converts spa to obs again, this time it's the format rather than the color space.
As you can see from the array above, it too only supports a single 10-bit color format.

From my understanding, an image is non-linear only if it's either using a 10-bit format, or HDR PQ/HLG color space.

HDR isn't supported, so the only check that needs to be done is checking for a 10-bit color format.

So revert has to be considered.

Have you considered my branch posted in the original issue? On my machine, this fixes all the issues reported and I would like testing on compositors with hardware cursor support (as NVIDIA and hardware cursors don't really do well together). I can open a pull request right away, or wait for you or other people to test this. Just let me know!

Of course I totally understand why a revert is appropriate as well.

[tytan652]

I disagree. Take a look at video_colorspace_from_spa_color_matrix in line 602 of pipewire.c. This hardcodes all supported color spaces to these few, likely because the original pipewire code does not support any other to begin with (though I couldn't find the source code responsible for this).

This is not used by the ScreenCast portal code, this is for the Camera one.

[tytan652]

Have you considered my branch posted in the original issue? On my machine, this fixes all the issues reported and I would like testing on compositors with hardware cursor support (as NVIDIA and hardware cursors don't really do well together). I can open a pull request right away, or wait for you or other people to test this. Just let me know!

I missed it. You should open a PR that as an alternative fix for the mentioned issue to attract more eyes, if you wish to go on that journey.

[RytoEX]

Does this chunk not need to be reverted?
4dfd0b3#diff-17471d738678ee9da05aa5f7e85201218d673609366b23cf07ddca571fd28ba7L794-R797

Contemplating if this should just be a clean revert.

[tytan652]

I somehow forgot to keep that part in the revert.

[RytoEX]

Though I think this would be fine as a clean revert without the FIXME (to ostensibly make it easier to re-apply the original commit and then fixes for it), this is probably fine until #12424 is finalized.