HDR content performance

[Ptilopsis01]

Important Information

Provide following Information:

• mpv version v0.37.0-70-g562450f5
• Windows Version win11 22631.2792
• Source of the mpv binary https://github.com/zhongfly/mpv-winbuild
• If known which version of mpv introduced the problem not quite sure
• Possible screenshot or video of visual glitches
  
  

Reproduction steps

The HDR content behaves low saturation when playing fullscreen(p2), which will not happen with maximum window(p1). But they are the same in the pictures when I tried to take a screen shot, so I have to take photos of the screen. I'm not sure whether it's the problem of my settings or mpv or my monitor.

(I've already turned windows HDR mode on, and my monitor supports HDR400.)

Expected behavior

HDR content plays correctly when playing fullscreen.

Actual behavior

Log file

mpv.log

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.

[Traneptora]

What happens if you use --no-config --vo=gpu-next? You have some things in your config that could interfere like 'vf-append' = 'format=colorlevels=full:colormatrix=bt.709:dolbyvision=yes'

[hooke007]

format=colorlevels=full would break all SDR colors, why you set this option.
dolbyvision=yes is enabled by default. You do not need set it.
'icc-profile-auto' = 'yes' BTW， I don't think your local icc suport hdr.

[Ptilopsis01]

What happens if you use --no-config --vo=gpu-next? You have some things in your config that could interfere like 'vf-append' = 'format=colorlevels=full:colormatrix=bt.709:dolbyvision=yes'

It behaves correctly when using --no-config --vo=gpu-next
It also behaves better than the original one with my settings except the vf-append attribute (but still different from the one using --no-config --vo=gpu-next or maximum window)

[Ptilopsis01]

format=colorlevels=full would break all SDR colors, why you set this option.

So what did this option do? I think that my monitor supports full level, but many videos are "limited", which may behaves strange.

'icc-profile-auto' = 'yes' BTW， I don't think your local icc suport hdr.

Well, actually I set this to "no" in the HDR profile.

[hooke007]

It's a fiter to mark the src video to be full range. So mpv would not transfer it correctly when playback.

[Ptilopsis01]

By the Way, the window size is larger than the monitor when it's maximum. Maybe it's a bug.

[hooke007]

Setting option 'border' = 'no' (flags = 4) Because you were using this option.
Not recommended on windows. See #9943 and more issues about --border with Windows.

[kasper93]

Setting option 'border' = 'no' (flags = 4) Because you were using this option.
Not recommended on windows.

Huh? Not recommended why? --title-bar=no behaves better indeed. But needs fixes from #12894

But no-border is also a viable option if the user wants that look.

By the Way, the window size is larger than the monitor when it's maximum. Maybe it's a bug.

Will try on my end when I get some time.

[Ptilopsis01]

I also found that target-colorspace-hint has an effect on the output when playing fullscreen, which caused this:

It also behaves better than the original one with my settings except the vf-append attribute (but still different from the one using --no-config --vo=gpu-next or maximum window)

[kasper93]

I also found that target-colorspace-hint has an effect on the output when playing fullscreen

It sends HDR data to your display. Which works only in fullscreen.

[Ptilopsis01]

It sends HDR data to your display. Which works only in fullscreen.

So it's not recommended if the monitor is not good at handling HDR contents?

[hooke007]

@kasper93 Here is another serious issue about no-border tomasklaen/uosc#811.

[Jules-A]

@kasper93 Here is another serious issue about no-border tomasklaen/uosc#811.

Yeah... borderless windowed-fullscreen is super broken in MPV, to keep the taskbar I have to use

snap-window
geometry=2560x1400+0+0
no-border

which gets it usable but this bug is really annoying...

[kasper93]

@hooke007 @Jules-A Works as expected and designed by Microsoft. Use --no-titlebar --border if you want to have compositor features.

[kasper93]

This is not true, as long as Windows HDR is turned on, the metadata is always sent to the monitor, whether it is full screen or not.

Not true, it is only sent in fullscreen (when window fully covers display area). In windowed mode you get DXGI clipping to current mode, but it doesn't use video metadata and display never gets them.

See #10628 for full information on Windows behavior.

[Jules-A]

@hooke007 @Jules-A Works as expected and designed by Microsoft. Use --no-titlebar --border if you want to have compositor features.

AHAHA no, that's way more broken, if you move or resize the window the titlebar returns, you have an ugly border and part of the window is cut off below the taskbar due to re-addition of the titlebar...

For what it's worth, my config is still considered fullscreen for freesync purposes but I didn't try if HDR features worked properly (my monitor's HDR is garbage so not worth using).