VLC3 HDR10 video is washed out compared to VLC4

[conartist6]

I was trying to watch an HDR10 movie and I wanted to be sure that it was rendering correctly. I actually tried four different players to see what the content "should" look like, and the result was that VLC3 had an image that looked "washed out", especially compared to VLC4, whose image looked even perhaps a bit supersaturated.

Initially I thought this was a failure to decode or display in 10bit HDR, but the more I read and poked into debugging output I began to suspect something different, which I have just confirmed: VLC3 selected a different colorspace than VLC4. My monitor Here's what I saw:

Both players selected direct3d11 output.

Code: Select all

main debug: using vout display module "direct3d11"

VLC 3.0.16 selected the RGB Rec.709 colorspace

Code: Select all

direct3d11 debug: Created the D3D11 device type 1 level b100. direct3d11 debug: NVIDIA WDDM driver 30.0.14.7168 direct3d11 debug: supports colorspace RGB Rec.709 gamma:22 range:FULL direct3d11 debug: supports colorspace RGB Rec.709 gamma:22 range:STUDIO direct3d11 debug: supports colorspace RGB Rec.2020 gamma:22 range:STUDIO direct3d11 debug: supports colorspace RGB Rec.2020 gamma:22 range:FULL direct3d11 debug: supports colorspace RGB Rec.2020 gamma:2084 range:FULL direct3d11 debug: supports colorspace RGB Rec.2020 gamma:2084 range:STUDIO direct3d11 debug: Output max luminance: 400.0, colorspace RGB Rec.709 gamma:22 range:FULL, bits per pixel 8 direct3d11 debug: using colorspace RGB Rec.709 gamma:22 range:FULL direct3d11 debug: Using pixel format VA_P010 for chroma DX10

VLC nightly-win64/20210915-0421 selected the RGB Rec.2020 colorspace, which for me was the correct result

Code: Select all

direct3d11 debug: Using pixel format VA_P010 for chroma DX10 direct3d11 debug: UpdateRects source offset: 0,0 visible: 3840x1600 decoded: 3840x1664 direct3d11 debug: UpdateRects image_dst coords: 0,0 3840x1600 direct3d11 debug: supports colorspace RGB Rec.709 gamma:22 range:FULL direct3d11 debug: supports colorspace RGB Rec.709 gamma:22 range:STUDIO direct3d11 debug: supports colorspace RGB Rec.2020 gamma:22 range:STUDIO direct3d11 debug: supports colorspace RGB Rec.2020 gamma:22 range:FULL direct3d11 debug: supports colorspace RGB Rec.2020 gamma:2084 range:FULL direct3d11 debug: supports colorspace RGB Rec.2020 gamma:2084 range:STUDIO direct3d11 debug: using colorspace RGB Rec.2020 gamma:2084 range:FULL

The monitor itself is an Acer, and claims to support "90% DCI-P3 Color Space".

[conartist6]

I dug a little into the source just to see where those messages are being printed.

3.x prints them here.
My 4.x nightly prints them here.

One very interesting thing I notice is that my VLC4 output does not include the "Output max luminance" line, which if present indicates that an alternate algorithm (based on dxgiOutput6->GetDesc1()) was used to select the best colorspace. Instead what seems to be happening is that the newer version is falling back to a more basic algorithm which for me actually works correctly.

[conartist6]

Now my questions are, "why is this happening," and also "what should be happening?"

As for why there are two possible reasons for the DXGI colorspace selection algorithm not to be used. Either one of three system calls did not succeed, or HAVE_DXGI1_6_H was not defined in the compilation environment. I think it's reasonably safe to assume the latter. The system calls are (I presume) the same calls on the same system in seemingly largely unchanged code in each version, so I find it relatively unlikely that they would behave differently. It seems more reasonably to assume that the nightly build server is not the same server as the one that build the production 3.0.16 release, and may be configured differently.

If I intuit this correctly it would mean that it's a build environment fluke that VLC4 is not having the same issue as VLC3, making this very decidedly a bug.

As to what should be happening... well, maybe someone can tell me if I file this as an issue? Which I shall go do.

[ePirat]

You probably should file an issue for this at https://code.videolan.org/videolan/vlc/-/issues