HDR color temperature looks different depending on the backend (dmabuf-wayland and gpu-next with waylandvk)

[Lassebq]

mpv Information

mpv v0.39.0-987-g415b70dc7 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Mar  7 2025 22:45:02
libplacebo version: v7.349.0
FFmpeg version: n7.1
FFmpeg library versions:
   libavcodec      61.19.100
   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: Linux arch 6.14.0-rc1 #1-Alpine SMP PREEMPT_DYNAMIC Wed, 05 Feb 2025 02:44:22 +0000 x86_64 GNU/Linux
- GPU Model: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev e7)
- Mesa/GPU Driver Version: Mesa 25.0.1-arch1.1
- Window Manager and Version: GNOME Wayland 48.rc
- Source of mpv: AUR
- Latest known working version: None

Reproduction Steps

ENABLE_HDR_WSI=1 mpv --no-config --target-colorspace-hint --vo=gpu-next <HDR Video>

and

mpv --no-config --target-colorspace-hint --vo=dmabuf-wayland <HDR Video>

Expected Behavior

Accurate color reproduction regardless of backend (I don't know which of the two is correct)

Actual Behavior

Different color temperature depending on used backend

Log File

output-dmabuf.txt

output-gpu-next.txt

Sample Files

https://www.youtube.com/watch?v=8a6TnOGyKBw

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

• [x] I tested with the latest mpv version to validate that the issue is not already fixed.
• [x] I provided all required information including system and mpv version.
• [x] 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.
• [x] I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• [x] I attached the full, untruncated log file.
• [x] I attached the backtrace in the case of a crash.

[CounterPillow]

today in "users who don't know what dmabuf-wayland is but choose to use it anyway"

[llyyr]

Can you try with mesa main instead of https://github.com/Zamundaaa/VK_hdr_layer ? The latter says "Hacks. Don't use for serious color work"

[kasper93]

Could you also try --gamut-mapping-mode=clip for gpu-next case?

[llyyr]

If you explicitly specify --hwdec=no with --vo=dmabuf-wayland, does the green tint go away?

[Lassebq]

My GPU doesn't support VP9 vaapi so --hwdec=no made no difference --gamut-mapping-mode=clip with --vo=gpu-next looks the same I would've tried latest mesa commit but freedesktop git is down..

[llyyr]

Hmm... I could reproduce the issue and it was related to vaapi uploads / format conversion. FWIW gpu-next output is correct. Does --vf=format=rgb30 help?

[Lassebq]

Yep --vo=dmabuf-wayland with --vf=format=rgb30 looks exactly like with --vo=gpu-next

[Dudemanguy]

Format conversions not being perfect makes sense and would explain this. That said, yuv420p10 should convert to p010 just fine. I'm not if that conversion is the problem or the upload to hardware. You could try to specify --hwdec=vaapi to maybe skip a conversion step if your GPU supports hwdec on this format.

[kasper93]

Yep --vo=dmabuf-wayland with --vf=format=rgb30 looks exactly like with --vo=gpu-next

gpu-next converts to rgb and sends this to wayland. dmabuf-wayland (in your cases) doesn't do any conversions and sends the data to wayland. Then the compositor likely is doing different conversion to rgb.

I'm quite confident in placebo conversion in this case. I didn't look at Mutter at all, so I cannot say they are wrong here. But I would suggest reporting the issue to GNOME/mutter. I don't see how it's mpv fault. We send the data and colorimetry info.

Also by doing --vf=format=rgb30 we force software conversion to rgb30 before it goes to rendering, so this confirms that libplacebo does the same conversion as zimg (or swscale).

Note I didn't debug it, but assuming mpv correctly sends metadata, it would be on Mutter side to fix.

[Lassebq]

I lack the technical knowledge behind this topic so I would appreciate if someone else could report it to mutter. Would also be great if anyone could confirm that Plasma is not affected by this issue.

[llyyr]

Would also be great if anyone could confirm that Plasma is not affected by this issue.

It is. I reproduced the issue on Kwin.

[ValeZAA]

23843b4aa594dc8c885575f3d237cde3c29398a2 made target-colorspace-hint=yes the default... Why are you still using it? And why are you using it without the yes or auto?

Accurate color reproduction regardless of backend (I don't know which of the two is correct)

There is no way for us to tell either because your screenshots are SDR and yet you are playing VP9 profile 2 which is 10 bit and tagged as PQ, so is indeed HDR... Do you even use HDR display?

I will experiment on SDR Windows 11 24H2. I would say this is primaries issue, the file is tagged as BT.2020 primaries, which is kinda a strong recommendation in modern PQ files. You see if it was issue with PQ (a.) the colors would be all crazy gray and liveless and really wrong. Matrix difference between BT.2020 and BT.709 is almost not noticible (b.) and it is done in HARDWARE correctly. Primaries are hard to handle and many people do not even understand what they are doing, like some people never understood that mastering metadata is not primaries, and primaries is how the video should be decoded. Even haasn I think... This is option (c.)

a) Lets override PQ with simple BT.709 and target (incorrectly) gamma 2.4 display, not typical of the LCD/OLED (dah)

mpv.com --target-trc=bt.1886 --vf=format=gamma=bt.1886 --target-colorspace-hint=no -vo=gpu-next -gpu-api=d3d11 -hwdec=nvdec-copy --ytdl-raw-options=cookies-from-browser=firefox https://www.youtube.com/watch?v=8a6TnOGyKBw

The image looks like this, I hope you understand that it is not PQ (even funnier if you were to also target PQ)

Now b)

Lets change the matrix not touching PQ or primaries, as you can see PQ is just too drastic, it is always obvious when the issue is with PQ. Here I will give you comparison page between bt709 matrix and bt2020 matrix, as you can see the difference is just so small that it cannot be your issue, you can only see it if you look at the scarf. https://slow.pics/c/LODFk9Qv

mpv.com --target-trc=bt.1886 --vf=format=colormatrix=bt.601 --target-colorspace-hint=no -vo=gpu-next -gpu-api=d3d11 -hwdec=nvdec-copy --ytdl-raw-options=cookies-from-browser=firefox https://www.youtube.com/watch?v=8a6TnOGyKBw

mpv.com --target-trc=bt.1886 --vf=format=colormatrix=bt.2020-ncl --target-colorspace-hint=no -vo=gpu-next -gpu-api=d3d11 -hwdec=nvdec-copy --ytdl-raw-options=cookies-from-browser=firefox https://www.youtube.com/watch?v=8a6TnOGyKBw

Now c) most likely. Here we will use PQ and bt2020-ncl correctly, but will ask it to use bt.709 primaries. Then we basically get your first image and then your 2nd image is correct. Now, it is possible there are two issues and matrix is also incorrect, but I am not analysing this.

So this has nothing to do with tonemapping.

mpv.com --pause --target-trc=bt.1886 --vf=format=primaries=bt.709 --target-colorspace-hint=no -vo=gpu-next -gpu-api=d3d11 -hwdec=nvdec-copy --ytdl-raw-options=cookies-from-browser=firefox https://www.youtube.com/watch?v=8a6TnOGyKBw

mpv.com --pause --target-trc=bt.1886 --vf=format=primaries=bt.2020 --target-colorspace-hint=no -vo=gpu-next -gpu-api=d3d11 -hwdec=nvdec-copy --ytdl-raw-options=cookies-from-browser=firefox https://www.youtube.com/watch?v=8a6TnOGyKBw

[Lassebq]

The color inaccuracy persists through SDR screenshots I attached. The only difference I can see to the displayed HDR image is clouds looking more flat. However, that's irrelevant.

I can also confirm the color inaccuracy looks exactly as what I'm seeing on an HDR-capable display with a Wayland compositor that supports wp-color-management-v1.

--vo=gpu-next with updated Mesa driver looks the same as VK_hdr_layer and the only difference appears to be format changing from rgb10a2 to bgr10a2

To reiterate, --vo=dmabuf-wayland with --vf=format=rgb30 looks proper without any green tint.

[Zamundaaa]

With mpv git master I see no difference between dmabuf-wayland on Plasma git master (with P010 support), dmabuf-wayland on Plasma 6.3 (without P010 support, so mpv converts to rgb) and gpu-next.

[ValeZAA]

The color inaccuracy persists through SDR screenshots I attached.

That is wrong. SDR assumptions are completly different. Anyway, further thinking about it it appears that both matrix is wrong and primaries. Gpu-next is color accurate. PQ is color managed correctly in both cases. You cannot garantee anything on sdr display without software color managment, so stop naivity here.

Bottom line: has nothing to do with tonemapping. It is basic color management that is wrong.

[Headcrabed]

@Lassebq Can you still reproduce this issue now?

[Lassebq]

Yes, still happens on GNOME

[Lassebq]

https://gitlab.gnome.org/GNOME/mutter/-/issues/3979

[Headcrabed]

@Lassebq can you try mpv git master and newest mutter or any other compositor that has color representation protocol implemented? Maybe color representation protocol would help about this issue.

[kode54]

How does this behave on Plasma 6.5 now? I still can't get mpv gpu-next on Vulkan to display unsquashed brightness of the following jxl file unless I disable the tonemapping filter. Also, Plasma 6.5 now reports the preferred transfer function of gamma 2.2 instead of either sRGB or PQ, so I'm not sure if that's relevant or not, since it's breaking other things like Gamescope.

hwdec=auto
vo=gpu-next
gpu-api=vulkan
gpu-context=waylandvk
profile=high-quality
target-colorspace-hint
ytdl-format=bestvideo[vcodec^=av01]+bestaudio/bestvideo[vcodec!^=av01]+bestaudio/best
ytdl-raw-options-append="cookies=~/<path to>/youtube.cookies.txt"
cookies=yes
cookies-file=~/<path to>/youtube.cookies.txt
slang=eng,en
screenshot-format=jxl

mpv-shot0001.jxl.gz

[llyyr]

How does this behave on Plasma 6.5 now? I still can't get mpv gpu-next on Vulkan to display unsquashed brightness of the following jxl file unless I disable the tonemapping filter. Also, Plasma 6.5 now reports the preferred transfer function of gamma 2.2 instead of either sRGB or PQ, so I'm not sure if that's relevant or not, since it's breaking other things like Gamescope.

This issue is tracking something completely unrelated to what you're describing.

This issue is for incorrect yuv->rgb conversion, which is fixed by the compositor supporting color-representation.

[kode54]

Sorry, I'll post a separate issue.