vo_gpu_next/d3d11: --target-colorspace-hint always assumes HDR passthrough

[norinoriko]

mpv Information

mpv 168fb56 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Nov  6 2024 17:15:09
libplacebo version: v7.349.0
FFmpeg version: b862792
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

- Windows version: Version 10.0.22631.4391
- GPU model, driver and version: AMD 24.10.1
- Source of mpv: CI
- Issue started after the following happened: 23843b4aa594dc8c885575f3d237cde3c29398a2

Reproduction Steps

Open an HDR video using gpu-next and the d3d11 backend.

Expected Behavior

HDR -> SDR tonemapping

Actual Behavior

Colorspace targets are set to BT.2020/PQ.

[   0.295][v][vo/gpu-next/libplacebo] New swap chain configuration received from hint: format: R10G10B10A2_UNORM, color space: RGB_FULL_G2084_NONE_P2020.

Vulkan still targets SDR as expected.

Log File

mpv.log

Sample Files

Reproducible on all HDR files

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.

[kasper93]

Disable HDR in Windows settings if you don't want to use it or set -target-colorspace-hint=no.

[norinoriko]

The display isn't HDR. I don't have an option to enable/disable HDR in the first place.

[kasper93]

Ok, nowadays Windows compositor does the tone-mapping.

[norinoriko]

It's not very high quality or stable. Having this be the default instead of shader-based tonemapping does not seem to be desirable behavior if you have an SDR display.

But if this is the new normal, then so be it. I'm not here to argue.

[kasper93]

But if this is the new normal, then so be it. I'm not here to argue.

Not arguing, just stating the fact. The same thing will happen on linux. mpv doesn't detect the actual display parameters, before decision about hdr passthrough is made. We could add this and add an --target-colorspace-hint=auto option. I hear you that mpv tonemapping in most cases will be superior to whatever is downstream.

/cc @Dudemanguy

[Dudemanguy]

Oh I thought --target-colorspace-hint already would not doing anything if the right swapchain couldn't be selected. I wouldn't have added the commit if made a difference on sdr displays.

[kasper93]

if the right swapchain couldn't be selected.

Swapchain can be selected, HDR is supported by compositor. So we can send HDR content. Thing is that the quality of mpv tone-mapping is higher.

[llyyr]

not doing anything if the right swapchain couldn't be selected

That is correct, but windows seems to always expose HDR swapchain (on d3d11) even if the monitor is SDR is the issue here

[Dudemanguy]

If this is only a problem on windows, I would say probably d3d11 should be fixed assuming that's not unreasonable. It was my expectation that --target-colorspace-hint would gracefully do nothing on SDR. I think vulkan always selects sdr? But maybe that's just because hdr support on linux is still half-complete or something.

[llyyr]

But maybe that's just because hdr support on linux is still half-complete or something.

Based on the mesa wsi MR, HDR swapchains will only be exposed if the compositor is actually advertising HDR support. So it's upto compositors not advertise color spaces that the monitor doesn't support by e.g. reading the edid

[kasper93]

If this is only a problem on windows, I would say probably d3d11 should be fixed assuming that's not unreasonable. It was my expectation that --target-colorspace-hint would gracefully do nothing on SDR. I think vulkan always selects sdr? But maybe that's just because hdr support on linux is still half-complete or something.

I think, conceptually, there is nothing stopping a compositor from advertising HDR support if it wants to perform tone mapping without display support.

Based on the mesa wsi MR, HDR swapchains will only be exposed if the compositor is actually advertising HDR support. So it's upto compositors not advertise color spaces that the monitor doesn't support by e.g. reading the edid

Yes, but as mentioned above, I think it’s possible for compositors to implement some level of HDR support, even if the display itself isn’t HDR-capable. There is certainly value in having support like that. mpv is superior because it has a complete HDR pipeline, but many applications may simply want to display HDR content and let the compositor handle the rest.

Either way, it should be fairly easy to add =auto mode, same as we have for dithering. I will try to do it this weekend.

[norinoriko]

This is purely speculative as I don't know the state of HDR passthrough on Windows+AMD+Vulkan, but the 10-bit surface on Vulkan only supports COLOR_SPACE_SRGB_NONLINEAR_KHR on my system, which is probably why --target-colorspace-hint works perfectly fine on that backend. I don't know if a driver update in the future has the potential to mess up querying and behave like d3d11 in the future.

[Dudemanguy]

At least on the wayland side, it would be my expectation that a compositor would only advertise HDR surfaces if the display actually supports it. But I guess in theory there is nothing stopping a compositor from implementing their own tonemapping. That's probably years away realistically.

But anyways, an auto mode for this purpose sounds reasonable to me.

[Doofussy2]

An auto option would be very welcome.

[kasper93]

See #15279