Gamma error when using deband with video-sync=display-

[Doofussy2]

Important Information

Windows 10

mpv 0.31.0-87-gae0520cafc Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
built on Sun Jan 26 08:51:40 +08 2020
ffmpeg library versions:
libavutil       56.38.100
libavcodec      58.66.101
libavformat     58.35.104
libswscale      5.6.100
libavfilter     7.71.100
libswresample   3.6.100
ffmpeg version: git-2020-01-25-15d160cc0

Reproduction steps

Run Windows in HDR. --d3d11-output-csp=pq will automatically be used. Use this config:

video-sync=display-vdrop
deband

Play any SDR video. The gamma is set very high, and making the picture very bad. If you pause playback and resize the window, the gamma changes. It's still incorrect, as reported here, but is now watchable.

When not using --video-sync=display-vdrop, or you disable --deband this error doesn't happen. But if you add a --scale option and disable --deband, you still get the problem with the gamma. I have not tested with other --video-sync options.

If you now play an interlaced video and add --deinterlace=yes to the config, the gamma now flashes, severely. Making it unwatchable (unless you want a seizure).

Expected behavior

To play with correct gamma

Log file

Deinterlacing.txt

Pause and resize.txt

[haasn]

Does fbo-format=rgba32f help?

[Doofussy2]

Does fbo-format=rgba32f help?

Sadly, no. Any idea why this is happening?

[ghost]

vdrop really doesn't do much. I think it might generate frames with num_vsync=0. I bet this has something to do with the d3d swapchain, CC @rossy @jeeb.

[Doofussy2]

Yeah, I was thinking the same thing.

[Doofussy2]

@jeeb any thoughts on this?

[Doofussy2]

This is still completely broken. I would like to be able to use --video-sync, but as is, it can't be applied. Is there any further investigation?

[Doofussy2]

A new discovery. When enabling --interpolation, the video is played correctly.

[Doofussy2]

The issue with the gamma is a pretty big one. VLC has none of these issues. Gamma is always correct. Is there any progress on this?

[ghost]

If VLC works, just use that.

[Doofussy2]

Oh man! Lol... Apart from this snafu, mpv is better. Using auto-profiles, I can correct the gamma, but using --video-sync=display- the picture loses its shit. I know you guys hate Windows, but is this really so difficult to correct that it won't be looked into? Allowing the d3d colorspace to be set at run-time would also work. Then I can just use that in an auto-profile.

[ghost]

I don't know, I think nobody knows the cause of this and/or could reproduce this, so nothing is happening.

[Doofussy2]

If I could set the colorspace to sRGB at run-time, and make auto-profiles for SDR and HDR content, that would fix everything. The gamma is lowering at the swapchain layer, not in mpv. And it's only when the swapchain is set to PQ. But obviously PQ is needed for HDR content, which I have lot of. So I need both options.

[Doofussy2]

Ok, I think I've got this figured out. You have to add --target-trc=pq as well as the d3d swapchain being set to pq. I guess I just thought that was automatically set, but it looks like it defaults to sRGB. When I manually set --target-trc=srgb, the gamma is cranked high, the same as I would observe when setting --video-sync=display-. Now, after setting trc to pq, no 'super' gamma.

That's one issue, resolved. Now, if I could set the d3d swapchain colorspace at runtime, we have ourselves a winning combination :) @jeeb

[Doofussy2]

@wm4 is this commit related to this issue? https://github.com/mpv-player/mpv/commit/c4b2ca83d6afc783b343a4b30d507234c224df40

I've discovered some HDR titles that the color/saturation appears to be incorrect if I don't also set --target-prim=bt.2020. And using frame advance there's some extreme over saturation, happening. Without setting the primaries, one frame will appear to be close to being correct, and the next will be way over. I used a close up of a woman's face, so I could look at skin tone. One frame has somewhat ordinary skin tone, next frame, complete red face.

The best I can do to illustrate what I'm talking about, is to take some pictures of my screen, with the frames I'm referring to.

So it looks like for us HDR guys, we should also be setting --target-trc and --target-prim ???

[ghost]

No.

[jeeb]

@Doofussy2 how I wrote the code and in my testing --d3d11-output-csp should work to set both primaries and transfer function, so setting either should not be in any way necessary unless you're trying to hack things somehow.

Mapping function from windows csp to mpv colorspaces: https://github.com/mpv-player/mpv/blob/152b0e2a8cb0f3c93de163a39e9c665cb515923f/video/out/gpu/d3d11_helpers.c#L230..L274

The logic that utilizes it: https://github.com/mpv-player/mpv/blob/152b0e2a8cb0f3c93de163a39e9c665cb515923f/video/out/gpu/d3d11_helpers.c#L784..L797

[Doofussy2]

Thanks @jeeb I appreciate you sharing that. But there is definitely something that needs adjusting. To illustrate, I took a series of pictures with different configs, to show the changes. Unfortunately, I'm not a photographer and I'm not using an SLR with light metering etc. So please allow for the elevated exposure. I did keep the lighting exactly the same for each shot, so the elevated exposure is consistent in all pictures.

Windows in SDR with both Windows and mpv at default (--no-config) for a baseline

Windows in HDR at 4:2:2 12bpc

--d3d11-output-csp=srgb

--no-config Sadly, due to the over exposure, this isn't showing how dark this actually is.

--deband with --video-sync=display-vdrop

--target-trc=pq --deband --video-sync=display-vdrop

--target-trc=pq --target-prim=bt.2020 --deband --video-sync=display-vdrop

--target-trc=pq --target-prim=bt.2020 --deband --video-sync=display-vdrop --gamma=14

Using --target-prim=bt.2020 desaturates a little, but the results should speak for themselves. Using sRGB for bt.709 content is clearly the best result. And if --deband and --video-sync=display- are to be used, then --target-trc=pq must also be applied if --d3d11-output-csp=pq is applied.

NOTE

When applying --d3d11-output-csp=srgb for SDR content, there is no gamma error when using --deband --video-sync=display-. So if --d3d11-output-csp=srgb could be used for SDR content and --d3d11-output-csp=pq used for HDR content, everything works, correctly.

[Doofussy2]

A small update. Using d3d11-output-format=rgba16f also fixes SDR playback, but unfortunately it breaks HDR. This too, is not able to be set at runtime. So that's another way to correct this.

d3d11-flip=no also has the same result, but not set at runtime.

For me, this is pretty much just broken. Using the workaround in the last picture, is my only option.

[Doofussy2]

OK, so this isn't limited to using --deband, it also happens with varying scaling options combined with --video-sync=display-.

[Doofussy2]

I think I've clearly shown there is something wrong, here. Any chance of being able to set --d3d11-output-csp= at runtime?

[Doofussy2]

Alright, so this time I just used Prt Scr to capture the images right from Windows.

All images are with Windows in HDR 4:2:2 12bpc

--d3d11-output-csp=srgb

--no-config There is a significant darkening. If watching a night scene, you lose most of the detail, and just get black. Yes, I have local dimming, enabled. But these pictures are not subject to that.

--deband with --video-sync=display-vdrop I mean... seriously. I'm attaching a trace log for this. gamma test.txt

--target-trc=pq --deband --video-sync=display-vdrop

--target-trc=pq --target-prim=bt.2020 --deband --video-sync=display-vdrop

--target-trc=pq --target-prim=bt.2020 --deband --video-sync=display-vdrop --gamma=14 The increase in gamma does balance most things, out. But In scenes where there is significant white, the white is now gray, and is over all more dim. I believe because of the use of --target-trc=pq