[Regression] Darker/crushed colors on Gnome Wayland (Fedora 43) - Nightly build > Dec 20

[Rahulbheda]

mpv Information

mpv --version
mpv v0.41.0-UNKNOWN Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.351.0
FFmpeg version: 7.1.2
FFmpeg library versions:
   libavcodec      61.19.101
   libavdevice     61.3.100
   libavfilter     10.4.100
   libavformat     61.7.100
   libavutil       59.39.100
   libswresample   5.3.100
   libswscale      8.3.100

Other Information

- Linux version:fedora 43
- Kernel Version:6.17.12-300.fc43.x86_64
- GPU Model:intel iris xe tigerlake
- Mesa/GPU Driver Version:Mesa 25.2.7
- Window Manager and Version:mutter
- Source of mpv: git verson
- Latest known working version:20 December nightly build
- Issue started after the following happened:after 20 december

Reproduction Steps

Description

I am experiencing a regression where colors appear significantly darker in the latest mpv nightly build compared to the build from December 20, 2025.

I am using mpv without any config (--no-config).

Reproduction Steps

1. Launch mpv with the latest nightly build on Fedora 43 with --no-config(Gnome/Wayland).
2. Play any video file.
3. Observe that the image is darker than intended.
4. Downgrade to the December 20, 2025 build.
5. Colors return to normal.

Build made from
https://github.com/terrapkg/packages/blob/f43/anda/apps/mpv/mpv-nightly.spec

Expected Behavior

Apected Behavior

Colors should match the rendering of the December 20 build (standard brightness/gamma).

Actual Behavior

Actual Behavior

The video output is noticeably darker.

Log File

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[llyyr]

Can you post logs from the version where it works? As well as screenshots that show what the difference actually looks like

[Rahulbheda]

Can you post logs from the version where it works? As well as screenshots that show what the difference actually looks like

BEFORE

AFTER

[llyyr]

Logs from the good build as well

[llyyr]

Can you check if this patch fixes it?

diff --git a/video/out/wayland_common.c b/video/out/wayland_common.c
index 57147d007965..e736a4693ff4 100644
--- a/video/out/wayland_common.c
+++ b/video/out/wayland_common.c
@@ -2167,7 +2167,9 @@ static void info_done(void *data, struct wp_image_description_info_v1 *image_des
                 wd->csp.hdr.max_fall = MPMIN(wd->csp.hdr.max_fall, wd->csp.hdr.max_luma);
         }
         wl->preferred_csp = wd->csp;
-        if (wd->csp.hdr.max_luma != PL_COLOR_SDR_WHITE && !pl_color_transfer_is_hdr(wd->csp.transfer)) {
+        if (wd->csp.hdr.max_luma &&
+            wd->csp.hdr.max_luma != PL_COLOR_SDR_WHITE &&
+            !pl_color_transfer_is_hdr(wd->csp.transfer)) {
             MP_VERBOSE(wl, "Setting preferred transfer to PQ for HDR output.\n");
             wl->preferred_csp.transfer = PL_COLOR_TRC_PQ;
         }

[llyyr]

@mahkoh why was the condition for this changed from max > reference luminance to max != PL_COLOR_SDR_WHITE (where PL_COLOR_SDR_WHITE would be the reference luminance after the conversion, I'm assuming)?

Mutter doesn't give us any information about the target at all, no primaries, no luminance no cll/fall... so we incorrectly output PQ for everything

[Rahulbheda]

Can you check if this patch fixes it?

diff --git a/video/out/wayland_common.c b/video/out/wayland_common.c
index 57147d007965..e736a4693ff4 100644
--- a/video/out/wayland_common.c
+++ b/video/out/wayland_common.c
@@ -2167,7 +2167,9 @@ static void info_done(void *data, struct wp_image_description_info_v1 *image_des
wd->csp.hdr.max_fall = MPMIN(wd->csp.hdr.max_fall, wd->csp.hdr.max_luma);
}
wl->preferred_csp = wd->csp;

•    if (wd->csp.hdr.max_luma != PL_COLOR_SDR_WHITE && !pl_color_transfer_is_hdr(wd->csp.transfer)) {
  

•    if (wd->csp.hdr.max_luma &&
  

•        wd->csp.hdr.max_luma != PL_COLOR_SDR_WHITE &&
  

•        !pl_color_transfer_is_hdr(wd->csp.transfer)) {
         MP_VERBOSE(wl, "Setting preferred transfer to PQ for HDR output.\n");
         wl->preferred_csp.transfer = PL_COLOR_TRC_PQ;
     }
  

i apply this patch but it not solve the issue and u are right,no issue until ae211f7

[mahkoh]

Mutter doesn't support color managent: https://gitlab.gnome.org/GNOME/mutter/-/issues/4438

[kasper93]

We probably should be friendly to Gnome folks and workaround this.

[mahkoh]

@mahkoh why was the condition for this changed from max > reference luminance to max != PL_COLOR_SDR_WHITE (where PL_COLOR_SDR_WHITE would be the reference luminance after the conversion, I'm assuming)?

If max lum is less than PL_COLOR_SDR_WHITE, then libplacebo nerds to know about that so that it can tonemap correctly.

What's described in the OP is expected. The only thing that's surprising is that the image is not completely black. I guess libplacebo has some kind of floor for tonemapping.

[kasper93]

What's described in the OP is expected. The only thing that's surprising is that the image is not completely black. I guess libplacebo has some kind of floor for tonemapping.

mpv does clamp tonemapping to 10 nits. But from the description it looks like we switch to PQ without luminance information, so it's mapped to 0-10000 nits. Which effectively disabled tonemapping, so things goes dark.

We can confirm this by looking at stats (shift+i).

We should reject 0 values from compositor, which are clearly bogus. Isn't this even protocol violation?

[mahkoh]

GNOME is blatently violating the protocol by not sending the messages at all.

[mahkoh]

But from the description it looks like we switch to PQ without luminance information

Max lum probably ends up negative after the conversion.

[llyyr]

I'm fine with calling this a Mutter issue, and telling people to disable color management in Mutter entirely since it violates the protocol.