The VideoLAN Forums

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.
VLC 3.0.16 selected the RGB Rec.709 colorspace VLC nightly-win64/20210915-0421 selected the RGB Rec.2020 colorspace, which for me was the correct result The monitor itself is an Acer, and claims to support "90% DCI-P3 Color Space".

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.

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.

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