mpv
mpv copied to clipboard
mpv-player
Wrong colorspace in Dolby Vision video (expect HDR, actual SDR)
Important Information
Provide following Information:
- mpv version mpv 0.34.0-142-g1ba0547bfb
- Platform and Version Windows 11 21H2 22000.438
- Source of the mpv binary https://downloads.sourceforge.net/project/mpv-player-windows/64bit/mpv-x86_64-20220116-git-1ba0547.7z
If you're not using git master or the latest release, update. Releases are listed here: https://github.com/mpv-player/mpv/releases
Reproduction steps
--vo=gpu-next --gpu-api=vulkan enable DoVi and play a dolby vision video
Expected behavior
Primaries: bt.2020 Colormatrix: ?? Gamma: ??
Actual behavior
Log file
Make a log file made with -v -v or --log-file=output.txt, paste it to https://0x0.st/ or attach it to the github issue, and replace this text with a link to it.
Sample files
Sample files needed to reproduce this issue can be uploaded to https://0x0.st/ or similar sites. (Only needed if the issue cannot be reproduced without it.) Do not use garbage like "cloud storage", especially not Google Drive.
Yeah, well. That is fake info, libplacebo does the render not counting for this.
Colormatrix: bt.2020-ncl
That would be false in any case scenario. It does not have any NCL matrix. The matrix is actually CL. :)
But yeah, it can be described as PQ and 2020 primaries for RGB matrix, I suppose, but still IPTPQc2 --> L'M'S' -> LMS --> RGB, so there is no R'G'B'!
I agree PRIMARIES MUST BE 2020 and transfer MUST be linear or PQ at least 12 bit. Gamma also is inverse so linear for linear and inverse PQ for PQ. BT.1886 is not inverse of 709, of course.
@haasn I think it should be linear transfer and 2020 primaries, matrix should be RGB, so Identity. There should also be a way to signal highest luminance like zscale does.
That way it can be "converted" to PQ for HDR.
Or if you like libplacebo being not transparent, just tag everything as unspecified.
The default target is SDR, so I'm not sure how this is an actual issue?
If you want HDR + 2020, specify it in your config:
target-trc=pq
target-prim=bt.2020
Maybe we should have separate properties for "tagged primaries" and "effective primaries". The latter notably also depends on the VO in use. At the moment only --vo=gpu-next will actually apply dolby vision.
What do you suggest should happen for something like profile 8.1?
What do you suggest should happen for something like profile 8.1?
shows base layer's info, add somethings like a tag of dolbyvision, like when playing hdr it would shows peak after gamma
The default target is SDR, so I'm not sure how this is an actual issue?
If you want HDR + 2020, specify it in your config:
target-trc=pq target-prim=bt.2020
That changes nothing. It still reads as SDR primaries.
Also, using pq ruins the picture. I run windows in HDR and the picture degrades when increasing the gamut and/or using pq transfer.
just tag everything as unspecified.
I will just point out AGAIN, that this is actually the case with profile 5 files (using IPTPQc2, they may not use it like those hacky Apple profile 5 screensavers, those should be looked into RPU, but more modern do actually use IPTPQc2), they omit VUI info! So... BT.709 is just the default that mpv uses, it is not what is in use in libplacebo, which is not transparent.
It still reads as SDR primaries.
Yes, because you should use --vf=format for this. But better not, since it is all done by libplacebo.
using pq ruins the picture
I suppose tonemapper should be turned off. And you need to force HDR context d3d11-output-csp=pq
using pq ruins the picture
I suppose tonemapper should be turned off. And you need to force HDR context d3d11-output-csp=pq
I don't think so. If I'm correct, there is no mechanism to hook the metadata to the windows swapchain, like the Dolby addon for windows. And no way to send the metadata to a DV enabled display. So tone mapping is all we have.
no mechanism to hook the metadata to the windows swapchain, like the Dolby addon for windows
Yes, dynamic metadata is not supported, but still you should force hdr to force 10 bit color (or better 12 bit) and force absense of SDR--> HDR inverse tonemapping of windows 11 and force absence of 709 --> 2020 primaries conversion windows does.
no mechanism to hook the metadata to the windows swapchain, like the Dolby addon for windows
Yes, dynamic metadata is not supported, but still you should force hdr to force 10 bit color and force absense of SDR--> HDR inverse tonemapping of windows 11 and force absence of 709 --> 2020 primaries conversion windows does.
Agreed. That would be a good thing.
I haven't upgraded to Win 11, yet. I don't have enough time to fix any breakages that might occur. So I'm waiting for a while.
fix any breakages that might occur
I thought there was a breakage in icc, but apparently they just destroyed the icc profile in main screen of colorcpl.exe, the advanced menu there still works perfectly. :)
Okay, I checked with HDR on. So not only it somehow select limited there and also it uses srgb though 10 bit surface is selected.
I currently have everything running with bt.2020 and pq, and I'm mostly satisfied with it. But with gpu-next, it isn't useable. I'm waiting to see what happens with the d3d11 PR. Hopefully it will sync up with Windows, like vo=gpu does. I can't really use DV tone mapping until that gets resolved, as there isn't a specific property for DV that allows me to create a profile to switch vo.
Hopefully it will sync up with Windows, like vo=gpu does
It did! --target-trc=pq --target-prim=bt.2020 --vo=gpu-next --gpu-context=d3d11 Build is here: https://github.com/ValZapod/mpv-winbuild/releases/tag/2022-02-03
[vo/gpu-next/d3d11] Using DXGI 1.2+
[vo/gpu-next/d3d11] Queried output: \\.\DISPLAY1, 3840x2160 @ 12 bits, colorspace: RGB_FULL_G2084_NONE_P2020 (12)
[vo/gpu-next/d3d11] Selected swapchain format R10G10B10A2_UNORM (24), attempting to utilize it.
[vo/gpu-next/d3d11] Selected swapchain color space RGB_FULL_G2084_NONE_P2020 (12), attempting to utilize it.
[vo/gpu-next/d3d11] Swapchain capabilities for color space RGB_FULL_G2084_NONE_P2020 (12): normal: yes, overlay: yes
[vo/gpu-next/d3d11] Swapchain successfully configured to color space RGB_FULL_G2084_NONE_P2020 (12)!
Also --target-trc=pq --target-prim=bt.2020 works, so THANKS @haasn!
I think this should be closed because the OSD menu prints metadata in VUI. Fullstop. Metadata in VUI is indeed full range SDR and other unspecified.
@haasn In HDR mode
[vo/gpu/d3d11] Queried output: \\.\DISPLAY1, 3840x2160 @ 12 bits, colorspace: RGB_FULL_G2084_NONE_P2020 (12)
[vo/gpu/d3d11] Selected swapchain format R10G10B10A2_UNORM (24), attempting to utilize it.
[vo/gpu/d3d11] Selected swapchain color space RGB_FULL_G2084_NONE_P2020 (12), attempting to utilize it.
[vo/gpu/d3d11] Swapchain capabilities for color space RGB_FULL_G2084_NONE_P2020 (12): normal: yes, overlay: yes
[vo/gpu/d3d11] Swapchain successfully configured to color space RGB_FULL_G2084_NONE_P2020 (12)!
the SWAPCHAIN color space RGB_FULL_G2084_NONE_P2020 defines what to target, not display's real capabilities, since the color management (and tonemapping ideally) MUST happen on display (WebOS). Yet it does not happen in gpu-next on Dolby Vision OR even HDR10 sources, why??? Manual --target-trc=pq --target-prim=bt.2020 --vo=gpu-next --gpu-context=d3d11 does work on Dolby Vision and HDR10 and looks reference to me. Normal HDR sources on vo gpu are not affected. I thought it is logical that swapchain causes the auto target to be on and if it does work with libplacebo then what is the problem?? I do not get it.
@jeeb To you too since you banned not collaborators under you pull. Again, your proposition of helper functions for libplacebo is inadecvate, because libplacebo does not need them. Swapchain happens in d3d11 code. Swapchain defines what to target, not libplacebo. So connecting normal mpv target-trc and target-prim (not libplacebo's) must be done with no touching libplacebo. Those are ALREADY connected to libplacebo (but vf format is not connected to libplacebo, at least in some scenarious).
as there isn't a specific property for DV that allows me to create a profile to switch vo.
@Doofussy2 try this profile-cond=(p["video-dec-params/gamma"] == "auto")
On mpv 0.34.0-221-g1c49d5735d still the same issue. ~~Also found that it interacts with inverse-tone-mapping option, which is incorrectly applied to the video that's definitely not SDR.~~ (Update: no it does not.)
Tonemapping also fails when target-trc=pq is not provided, clipping hard, despite output being set in HDR which should set it to that value by default. (regardless of d3d11-output-csp setting) The picture does not degrade when using PQ TRC. The picture hard clips without that. Additionally, not providing target-prim=bt.2020 oversaturates and clips the colors. Not providing target-peak at correct peak value will wash everything out, most likely.
tone-mapping setting is applied.
Please really verify against true DV output when saying "degrades the colors". It produces output comparable with "Cinema Home" (calibrated) settings on LG CX 48" in (calibrated) Game PC HGIG mode if:
tone-mapping=bt.2446a
target-trc=pq
target-prim=bt.2020
target-peak=570
(the peak is the calibrated peak value for my PC Game mode)
Obviously the DV is tonemapped back to HDR10 with the target settings, and the tonemap is slightly different from whatever dynamic thing DV chip is doing. Besides the settings issues, it looks pretty decent.
For reference, the check used Containers video from Demolandia, directly downloaded. NASA is better at uncovering wrong gamut - which it is, since there's no way to provide the display gamut to mpv just yet, maybe except target-lut... soon. Using static tonemap in the TV works correctly though.
Obviously the DV is tonemapped back to HDR10 with the target settings, and the tonemap is
It can/should be tonemapped to hdr12 too (12 bit pq), no problem.
Please really verify against true DV output when saying "degrades the colors". It produces output comparable with "Cinema Home" (calibrated) settings on LG CX 48" in (calibrated) Game PC HGIG mode if:
I agree!!
Additionally, not providing target-prim=bt.2020 oversaturates and clips the colors.
That should be obvious.
(the peak is the calibrated peak value for my PC Game mode)
Too low, did you get a bug in game mode? They fixed it.
Besides the settings issues, it looks pretty decent.
I know one example where it does not :)
Of course mpv does not do 12-bit PQ, because it uses d3d11 rgb10_a2 mode. That gives 10-bit output. It'd need a rgb16f scRGB output which it does not have yet.
There was no game mode peak bug, there was a case of someone not checking that the settings are vastly different. Rtings sucks. (I've measured the peaks, they're exactly the same. Getting some 600 nit before - at 10% D65 white point, calibrated. LG CX 48" is a bit darker than bigger ones. It does some 650 nit uncalibrated with warm setting.)
Of course in some content what mpv does now won't work best - especially if metadata is used to touch up the video a lot. mpv does not use any metadata from DV so far I think. (Also do tell which example.)
It'd need a rgb16f scRGB output which it does not have yet.
Yes. We in Chrome have it, BTW and use it for display p3 sdr photos too. But I was thinking about 12 bit non float. There should be one, right?
Rtings sucks.
I read it on avsforums. And it was mentioned by hdtvtest. It was fixed very fast.
mpv does not use any metadata from DV so far I think
No, it does not use any dynamic meta. And no NLQ yet on top of already done MMR. As for example it is here (maybe fixed already, who knows, will check): https://github.com/mpv-player/mpv/pull/9677#issuecomment-1007884324
Of course mpv does not do 12-bit PQ, because it uses d3d11 rgb10_a2 mode. That gives 10-bit output. It'd need a rgb16f scRGB output which it does not have yet.
Not necessarily, I think. I guess you need rgb16f half-floats on the side of mpv, yes, but you don't need another colorspace conversion, because, as far as I know, Windows' compositor does the conversion from any colorspace provided by the app to scRGB automatically?
colorspace provided by the app to scRGB automatically?
Android does that, not windows. And are you like being serious right now? HDMI uses PQ codepoints. And it needs XYZ for color managment on linear RGB. But no, scRGB is old technology and besides it uses old SDR curve and thus cannot be used for 10000 nits. No, we in chrome use for "HDR mode on" of windows 11 RGBA_F16 backbuffer and transfer linear_HDR (slope 0.6250, SDR white point 128 nits), matrix RGB, range obviously full. You can see it in chrome://gpu
Nah, I'm pretty sure that this applies to Windows.. well, a somewhat recent Windows 10, like 1903, or never, obviously
When "advanced color mode" is properly supported, the Windows compositor (DWM) does the conversion to scRGB before it then gets to the display color space..
Haven't tried this myself though, but if I remember correctly, that what's the Windows docs say..
the Windows compositor (DWM) does the conversion to scRGB before it then gets to the display color space..
I suppose you need to google what direct composition using SW overlays is. Certainly some older games' engines do use scRGB... But that is I think just WCG, nothing like 10000 nits. And I think there is support for YCbCr superwhite in MPC-HC, at least in windows renderer. Intel driver also can passthrough YCbCr untouched and that allows for superwhite and even for https://en.wikipedia.org/wiki/XvYCC
Found it... cause I like to back up what I'm saying... https://docs.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range
I played with a lot of different config values and I think I have found the "correct" way to display Dolby Vision with MPV in HDR. Here is my config
profile=gpu-hq
vo=gpu-next
hwdec=auto-copy
target-colorspace-hint=yes
hdr-compute-peak=no
target-trc=pq
target-prim=bt.2020
target-peak=1500
Please set target-peak according to your display. I guess for something like the LG CX 800 should be good.
I'd recommend setting target-peak not to true peak but to sustained 5% value or you will get noticeable dimming in enough bright scenes just due to total area of specular reflections. The newer screens are a bit better at it but will dim nonetheless.
The OLED being a true black screen is the real important piece anyway. In new mpv the tone mapping is set to something quite reasonable for bright conditions by default. The real problem is ABL but one fixable with a service remote. Aggressive enough ABL will ruin the DV mapping.
For example the QD-OLED Alienware can only do ~480 nit reliably, so target-peak is probably best set to that for DV mapping. Samsung QD-OLED needs to be in Filmmaker mode with maybe 1000 nits as peak.
Dobly Vision doesn't work for me. My LG C2 shows the HDR icon instead of Dobly Vision. I tried using a config file with only:
profile=gpu-hq
vo=gpu-next
hwdec=auto-copy
target-colorspace-hint=yes```
And nothing else. But it just goes to normal HDR mode
Dobly Vision doesn't work for me. My LG C2 shows the HDR icon instead of Dobly Vision.
That's the expected behaviour.
