vo_gpu_next/d3d11: --d3d11-output-format=auto selects the wrong output format

[norinoriko]

mpv Information

mpv v0.38.0-344-g2fa66b85 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on May 25 2024 00:09:40
libplacebo version: v7.349.0 (v6.338.0-133-g9e1257c-dirty)
FFmpeg version: N-115376-gaff24c165
FFmpeg library versions:
   libavutil       59.20.100
   libavcodec      61.5.104
   libavformat     61.3.104
   libswscale      8.2.100
   libavfilter     10.2.102
   libswresample   5.2.100

Other Information

• Windows version: Windows 11 10.0.22631.3593
• GPU model, driver and version: AMD 24.5.1
• Source of mpv: shinchiro
• Introduced in version: n/a

Reproduction Steps

mpv --vo=gpu-next --gpu-api=d3d11 <file>

Expected Behavior

libplacebo selects rgba8 because that's the configured bit depth of the device.

Actual Behavior

libplacebo selects rgb10_a2 instead, which results in the driver having to apply its own dithering in addition to whatever mpv is doing. --d3d11-output-format=rgba8 has to be stated explicitly.

Log File

mpv.log

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.

[kasper93]

--d3d11-output-format options doesn't really have control over libplacebo. Only supported value is --d3d11-output-format=rgba8 and still it is only a hint, to not use 10-bit for sdr.

I guess we can add a output depth check in libplacebo and prefer matching format.

Note that in many cases you will still get dithering in monitor, because while they can accept 8-bit signal, the actual output is another story. This we cannot do anything about.

[norinoriko]

I just assumed it's an issue because d3d11's behavior is inconsistent with vulkan, which does output rgba8 (which seems like the more "correct" thing to do but I dunno honestly).

I also tried opengl, but opengl seems to be broken in its own way, since the log doesn't show a selected format and the stats screen just shows "fbo".

Note that in many cases you will still get dithering in monitor, because while they can accept 8-bit signal, the actual output is another story. This we cannot do anything about.

Setting --d3d11-output-format=rgba8 causes banding on 16-bit color gradients if dither-depth is disabled, so I'm just making the assumption that since rgba10_a2 has no banding, there's some kind of internal dithering being applied.

[ruihe774]

I also tried opengl, but opengl seems to be broken in its own way, since the log doesn't show a selected format and the stats screen just shows "fbo".

There is [vo/gpu-next/libplacebo] (Re)creating 1920x1080x0 texture with format ... in the log showing the selected format. --fbo-format has no control over the format selection logic in libplacebo.

[norinoriko]

There is [vo/gpu-next/libplacebo] (Re)creating 1920x1080x0 texture with format ... in the log showing the selected format.

This is unrelated to output format. This part of the log shows the depth for the file format and the subsequent fbo-format precision.

--fbo-format has no control over the format selection logic in libplacebo.

I didn't say that it did. I'm just saying that the stats screen fails to display a format and just says "fbo" in plaintext.

This is off-topic to this issue and would need to be its own separate issue. I just made an off-hand comment about how other APIs treat the output format for comparison.

[ruihe774]

I also tried opengl, but opengl seems to be broken in its own way, since the log doesn't show a selected format and the stats screen just shows "fbo".

haasn/libplacebo#267

[lextra2]

not this sh*t again...
AMDs driver temporal dithers (at all times) to what ever bit depth your display is set to in their driver UI
Having MPV output 10bit or 8bit won't matter in that case.

[norinoriko]

See #14242 (comment)

[Jules-A]

not this sh*t again... AMDs driver temporal dithers (at all times) to what ever bit depth your display is set to in their driver UI Having MPV output 10bit or 8bit won't matter in that case.

Huh? I don't think it dithers if the output is already 10bit... If I don't set 10bit manually in MPV the image loses some detail compared to setting to 10bit and ordered in MPV (though it's been about 7 months since I last tested). I assume AMD is using a speed focused algorithm and the more expensive MPV options work out better quality.

[lextra2]

I assume AMD is using a speed focused algorithm and the more expensive MPV options work out better quality.

That would be correct.
Doesn't change the fact that AMDs dithering is always enabled (unless manually disabled with ColorControl)

@norinoriko
Manually set MPVs dither-depth to whatever has no banding for you.
There won't be a "catch-all" auto setting, especially not for Vulkan, which has no API support to read the current displays bit depth.

[norinoriko]

Manually set MPVs dither-depth to whatever has no banding for you.

No shit. This is not relevant to this issue. I'm not complaining about banding here, because there's no banding regardless of whether or not mpv selects rgba8 or rgb10_a2 (for all of the reasons I already reiterated, for the former case mpv is already dithering by default, and for the latter case both mpv and the GPU are dithering since the output has a higher bit-depth than the display).

I'm demonstrating a point that if you manually configure mpv to select the correct output format, you get less unnecessary filtering/noise which is always a net-positive. The core of the issue here is the output format selection does not match the device bit-depth.

[norinoriko]

I just assumed it's an issue because d3d11's behavior is inconsistent with vulkan, which does output rgba8 (which seems like the more "correct" thing to do but I dunno honestly).

Well, the funniest thing just happened actually. Ever since AMD 24.6.1, vulkan has started offering the rgb10_a2 format, which gets autoselected by mpv now.

[   0.098][v][vo/gpu-next/libplacebo] Picked surface configuration 2: VK_FORMAT_A2B10G10R10_UNORM_PACK32 + VK_COLOR_SPACE_SRGB_NONLINEAR_KHR

I can also confirm that selecting this output format enables built-in driver dithering, so now the behavior perfectly mirrors d3d11 on AMD systems, for better or worse.

Since vulkan doesn't really have a way of preferring an output format, I guess it's fair to say that this issue is FUBAR.

[lextra2]

Well, the funniest thing just happened actually. Ever since AMD 24.6.1, vulkan has started offering the rgb10_a2 format, which gets autoselected by mpv now.

Nice. Thanks for the info!
AMD has indeed added 10 bit support for vulkan with their newest 24.6.1 WHQL drivers.

C:\Windows\System32\vulkaninfo.exe shows a new entry for that under Presentable Surfaces > FORMAT_A2B10G10R10_UNORM_PACK32

Too bad they didn't write that into their patch notes.

[norinoriko]

Duplicate of #10881

See: #10881 (comment)