BT.2020 HDR video is washed out on dmabuf-wayland vo when shown on SDR monitor

[yejingchen]

mpv Information

mpv v0.40.0-329-gee0f70134 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Sep 23 2025 04:25:46
libplacebo version: v7.351.0
FFmpeg version: n7.1.1
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: Arch Linux
- Kernel Version: 6.16.8-arch1-1
- GPU Model: 63:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev d8)
- Mesa/GPU Driver Version: Mesa 25.2.3-arch1.2
- Window Manager and Version: kwin 6.4.5-3
- Source of mpv: archlinuxcn repo (https://github.com/archlinuxcn/repo/tree/master/archlinuxcn/mpv-git)
- Latest known working version: 0.40.0
- Issue started after the following happened: play an HDR BT.2020 video

Reproduction Steps

I am using a LG 27UL550-W monitor in SDR mode. Desktop environment is KDE Plasma 6.4.5 (Wayland), without setting ICC in KDE System Settings.

Download https://www.youtube.com/watch?v=T-rxE5vKlkg (with yt-dlp video format 335) and open it with mpv ~/Videos/'Trailer 2 ｜ One Battle After Another ｜ 4K HDR ｜ Dolby 5.1 #4K #10bit #Surround #Flat [T-rxE5vKlkg].webm' --vo=dmabuf-wayland --mute --pause --start=36 --no-config --hwdec=vaapi will show a washed out image.

While investigating, I tried setting WAYLAND_DEBUG environment variable to see the events, (full log here: mpv-wayland-debug.log) and noticed that wp_color_management_surface_v1#45.set_image_description only happens after wl_surface#6.commit, could it be related to the washed out image?

(...)
[3518704.473] {Default Queue}  -> wp_color_representation_surface_v1#63.set_coefficients_and_range(6, 2)
[3518704.475] {Default Queue}  -> wp_color_representation_surface_v1#63.set_chroma_location(1)
[3518704.478] {Default Queue}  -> wl_surface#6.attach(wl_buffer#60, 0, 0)
[3518704.481] {Default Queue}  -> wl_surface#6.damage_buffer(0, 0, 1920, 1038)
[3518704.486] {Default Queue}  -> wl_shm_pool#50.create_buffer(new id wl_buffer#64, 0, 1920, 1038, 7680, 0)
[3518704.727] {Default Queue}  -> wl_surface#7.commit()
[3518704.731] {Default Queue}  -> wl_surface#6.commit()  <-- This one happens...
[3518704.733] {Default Queue}  -> wl_surface#5.commit()
[3518704.984] {Display Queue} wl_display#1.delete_id(57)
(...)
[3518705.000] {Display Queue} wl_display#1.delete_id(58)
[3518705.002] {Default Queue} wp_image_description_v1#62.ready(171)
[3518705.006] {Default Queue}  -> wp_color_management_surface_v1#45.set_image_description(wp_image_description_v1#62, 0)   <-- before this
[3518705.009] {Default Queue}  -> wp_image_description_v1#62.destroy()
[3518705.012] {Default Queue} wl_buffer#55.release()
(...)

Expected Behavior

Compare to gpu-next:

command: mpv ~/Videos/'Trailer 2 ｜ One Battle After Another ｜ 4K HDR ｜ Dolby 5.1 #4K #10bit #Surround #Flat [T-rxE5vKlkg].webm' --vo=gpu-next --mute --pause --start=36 --no-config --hwdec=vaapi

Actual Behavior

The vo=dmabuf-wayland image looks washed out like this:

Log File

output.txt

Sample Files

https://drive.google.com/file/d/1252P04j0izxKbG87jgVbYAOSi-9PofQF/view?usp=sharing

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.

[yejingchen]

Interesting, if I use --vo=gpu-next --target-colorspace-hint=yes --target-colorspace-hint-mode=source (which I think is very similar to --vo=dmabuf-wayland w.r.t. presenting colors), wl_surface#5.commit does happen after wp_image_description_v1#99.ready and wp_color_management_surface_v1#97.set_image_description, and results a correct image.

wayland debug log: mpv-gpunext.log

[yejingchen]

Interesting, if I use --vo=gpu-next --target-colorspace-hint=yes --target-colorspace-hint-mode=source (which I think is very similar to --vo=dmabuf-wayland w.r.t. presenting colors), wl_surface#5.commit does happen after wp_image_description_v1#99.ready and wp_color_management_surface_v1#97.set_image_description, and results a correct image.

wayland debug log: mpv-gpunext.log

Does it imply a missing dependency or ordering between wp_image_description_v1.ready event and wl_surface.commit when using dmabuf-wayland vo?

[llyyr]

Does either vo switch your monitor to HDR mode? If not, then it's simply that libplacebo tonemapping HDR->SDR is much better than what Kwin does.

[yejingchen]

Does either vo switch your monitor to HDR mode?

No, both run under SDR mode as I didn't enable HDR in system settings.

However when testing 0.40.0 (mpv 1:0.40.0-6 from Arch Linux) I do noticed one thing: using the same command (mpv ~/Videos/'Trailer 2 ｜ One Battle After Another ｜ 4K HDR ｜ Dolby 5.1 #4K #10bit #Surround #Flat [T-rxE5vKlkg].webm' --vo=dmabuf-wayland --mute --pause --start=36 --no-config --hwdec=vaapi), although the final color is correct, there is a very brief moment when the image is washed out, before becoming correct, which I think is the out-of-order set_image_description coming into effect.

output.mp4

If not, then it's simply that libplacebo tonemapping HDR->SDR is much better than what Kwin does.

Given that mpv 1:0.40.0-6 with vo=dmabuf-wayland shows mostly the same image as vo=gpu-next, I think kwin's tonemapping is doing ok here 🤔

[kasper93]

Could you post screenshots with stats enabled also, for easier check of output/input params.

Given that mpv 1:0.40.0-6 with vo=dmabuf-wayland shows mostly the same image as vo=gpu-next, I think kwin's tonemapping is doing ok here 🤔

Could you bisect mpv to find when it regressed? This would be the fastest way to fix this.

[yejingchen]

Could you post screenshots with stats enabled also, for easier check of output/input params.

Sure:

• mpv v0.40.0-330-gbe98b35c8, dmabuf-wayland, washed out image:

• mpv v0.40.0-330-gbe98b35c8, gpu-next, seemingly correct color:

• mpv v0.40.0-330-gbe98b35c8, gpu-next with --target-colorspace-hint=yes --target-colorspace-hint-mode=source (tone mapping done by kwin as I understand it):

• mpv v0.40.0 (from Arch Linux), dmabuf-wayland, similar to gpu-next with target-csp:

Given that mpv 1:0.40.0-6 with vo=dmabuf-wayland shows mostly the same image as vo=gpu-next, I think kwin's tonemapping is doing ok here 🤔

Could you bisect mpv to find when it regressed? This would be the fastest way to fix this.

Will do.

[yejingchen]

Given that mpv 1:0.40.0-6 with vo=dmabuf-wayland shows mostly the same image as vo=gpu-next, I think kwin's tonemapping is doing ok here 🤔

Could you bisect mpv to find when it regressed? This would be the fastest way to fix this.

Will do.

699054cfd96b10699ba5da9dcee0028e796fa3b1 is the first bad commit
commit 699054cfd96b10699ba5da9dcee0028e796fa3b1
Author: Dudemanguy <random342@airmail.cc>
Date:   2025-07-14 13:17:12 -0500

    vo_dmabuf_wayland: use pl_color_space_infer on HDR transfers
    
    vo_gpu_next already does this. If we have HDR, try to fill out any
    missing values before doing validation.

 video/out/wayland_common.c | 1 +
 1 file changed, 1 insertion(+)

[llyyr]

Can you check if this patch fixes it?

diff --git a/video/out/wayland_common.c b/video/out/wayland_common.c
index 50962106c0d4..116d41b27306 100644
--- a/video/out/wayland_common.c
+++ b/video/out/wayland_common.c
@@ -3467,7 +3467,9 @@ static void set_color_management(struct vo_wayland_state *wl)
     wp_image_description_creator_params_v1_set_primaries_named(image_creator_params, primaries);
     wp_image_description_creator_params_v1_set_tf_named(image_creator_params, transfer);
 
-    pl_color_space_infer(&wl->target_params.color);
+    struct mp_image_params current_params = vo_get_current_params(wl->vo);
+    struct pl_color_space source_csp = current_params.color;
+    pl_color_space_infer_map(&source_csp, &color);
     struct pl_hdr_metadata hdr = wl->target_params.color.hdr;
     bool is_hdr = pl_color_transfer_is_hdr(color.transfer);
     bool use_metadata = hdr_metadata_valid(&hdr);

[yejingchen]

Can you check if this patch fixes it?

Yes, I applied it on top of be98b35, and it is no longer washed out: