search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.27k stars 2.9k forks source link

HDR behavior is not clearly documented #7357

Closed agyild closed 3 years ago

agyild commented 4 years ago

So I have a Samsung LC27HG70 monitor that apparently supports up to 600 cd/m2. In Windows I want to be able to watch HDR content at optimized settings. I have searched with "mpv + hdr", multiple results including github issues came up from few years back. And the more I read the more I got confused. I tried applying each different setting, they were all okay in a different fashion so I was not sure if I was doing it right. I have noticed if I enable Windows HDR mode and maximize my monitor's brightness and finally set target-peak to 600, HDR seems to be okay. But then everything on video overlay gets grayed out. So it obviously seems like a hack instead of a proper fix. I have a .icc profile that was generated in SDR mode and some people suggest enabling it in mpv config, some people suggest playing with hdr-peak and target-x options etc. It's just confusing. And manual only lists each option as a reference, it doesn't tell you what to do. Can you write what one needs to do watch HDR content from scratch with step-by-step instructions along with assumptions (e.g. Your monitor's brightness must be set at 100%, mpv should be fullscreen, Windows HDR should be enabled and calibrated to this etc.) you make for those instructions? How you do it and test it out in your environment?

NiLuJe commented 4 years ago

FWIW, I wouldn't qualify that monitor as a real HDR monitor (I should know, I have one). 4 or 6 backlight zones do not an HDR display make ;).

So, yeah, while it technically will support 10-bit output (with a not-that-great colorspace coverage), I'd basically avoid HDR at all costs on it.

agyild commented 4 years ago

FWIW, I wouldn't qualify that monitor as a real HDR monitor (I should know, I have one). 4 or 6 six backlight zones do not an HDR display make ;).

So, yeah, while it technically will support 10-bit output (with a not-that-great colorspace coverage), I'd basically avoid HDR at all costs on it.

I know it's not a top tier HDR monitor. But I am okay with getting closest results to HDR, it's still slightly better than SDR.

haasn commented 4 years ago

My honest opinion would be that, if you don't know what you're doing, not to play with any of those options. I don't think there's a "one size fits all" solution here because every monitor and every environment is different and it sort of comes down to what you actually want to accomplish, which requires having at least a basic understanding of what's possible.

Such a guide would probably help, but it'd have to be very much broken down by different types of platforms and use cases and I don't know enough about e.g. Windows to write a guide that would even be applicable to you. Maybe I'll give it a shot some day. For now, all I can recommend with a straight face is to just pretend HDR doesn't exist, it's mostly a pointless marketing gimmick anyways.

Doofussy2 commented 4 years ago

Your actual peak is probably considerably lower. The peak of my display is supposedly close to 2000nits. In reality, it's coming out at around 1000nits. You can't just crank the brightness, it doesn't quite work like that. There are a lot of variables. Display calibration is very specific.

agyild commented 4 years ago

What I want to do is taking a for instance a HDR1000 content and adapting it to my display's characteristics as much as possible. I am fine with default hable tonemapping. From trial and error I can see that if I don't set target-peak to a closer value to 600, some of the white content seems to blow and details disappear although everything seems to be brighter. So modifying target-peak seems the right thing to do. The only problem I have while Windows HDR mode is active overlay elements (OSD & subtitles) in mpv that is normally supposed to be in white, display in gray instead. Also SDR content seems dull while played in HDR (i.e. not equivalent to a YouTube SDR movie playback while HDR mode enabled). If I only could solve those, I could live with how things are by scripting SDR/HDR behavior.

Here is my baseline HDR setup:

  1. Display has been calibrated to 120 cd/m² and a default color profile has been created in DisplayCAL using i1Display Pro while the display is in SDR mode
  2. Windows HDR has been activated, and using i1Display Pro "SDR white" has been calibrated by taking a reference reading from a SDR white zone and lowering Windows HDR parameter to 39-40. That's where SDR white in HDR equals to my original 120 cd/m² setting as it should be.

So I am wondering how I should move on from here. I have some idea about color calibration, gamuts etc. So I would appreciate it if you could point me in the right direction. I just want a Netflix-app equivalent HDR experience in mpv, that's it.

In SDR, I am just using icc-profile-auto. Leaving it enabled in HDR causes brightness and colors to blow, so I disable it in HDR.

Doofussy2 commented 4 years ago

If you've calibrated it with display Cal to 120nits, did you apply it to Windows as the default? And from my own experience with that exact same setup, you need to apply the adjustment for the i1 and leave everything on auto so it measures everything. It's a colorimeter not a spectrometer.

agyild commented 4 years ago

If you've calibrated it with display Cal to 120nits, did you apply it to Windows as the default? And from my own experience with that exact same setup, you need to apply the adjustment for the i1 and leave everything on auto so it measures everything. It's a colorimeter not a spectrometer.

Yes, it is applied as the default and DisplayCAL manages the profile. I just modified White level to Custom and set 120 nits as the target. And also modified other settings that only affect the profile and calibration quality. Everything else is set to their default or auto values (D6500, 2.2 Gamma etc).

Doofussy2 commented 4 years ago

The other thing is, if you're using Windows 10, you don't need an icc. Just let the d3d swapchain do it's work.

AzureWolf commented 4 years ago

I've been having a "dim" everything (interface, video, subtitles, etc) on MPV and don't know if it's related to this issue so I thought I'd post here before making a separate one. The issue is very much like this: https://github.com/microsoft/vscode/issues/68069#issuecomment-461383197

Where it's not a color profile or video playback issue, but just the application overall is dim with an HDR screen. The solution that works there is to add --force-color-profile srgb, but that option doesn't exist here.

Sorry if this isn't the issue everyone is talking aobut here.

agyild commented 4 years ago

I've been having a "dim" everything (interface, video, subtitles, etc) on MPV and don't know if it's related to this issue so I thought I'd post here before making a separate one. The issue is very much like this: microsoft/vscode#68069 (comment)

Where it's not a color profile or video playback issue, but just the application overall is dim with an HDR screen. The solution that works there is to add --force-color-profile srgb, but that option doesn't exist here.

Sorry if this isn't the issue everyone is talking aobut here.

Yep. I am also having the same issue with mpv. Normally white GUI content appears dimmed out while HDR is active.

Doofussy2 commented 4 years ago

What GPUs do you guys, have? And how are they configured?

agyild commented 4 years ago

What GPUs do you guys, have? And how are they configured?

Don't think it's relevant since it's probably something in the API level. But still, I use a NVIDIA GeForce GTX 1080.

Doofussy2 commented 4 years ago

Well, I have a 2060, Windows 10, HDR enabled, 4:2:2 12bit, no config for HDR stuff and I get a perfect output.

jeeb commented 4 years ago

I have recently re-tested the current Windows D3D11 HDR support in general, and by default with PQ you get a target-peak of 10k, which should (more or less) pass all content through. So in that sense it actually by default works better than expected (I was expecting target-peak being at 100 nits by default for some reason). So yes, "just make sure your screen is getting detected as the one where the swap chain would get created" and it should auto-work on the most basic level.

If for some reason the HDR mode of your monitor is not getting auto-detected, --d3d11-output-csp=pq (possibly paired with --d3d11-output-format=rgb10_a2) is what you'd generally otherwise get with a 10bit+ connected screen with BT.2020+PQ configured,

Some current planned improvements would be:

Some things that can be useful to people for tweaking their experience from some of my testing sessions:

P cycle tone-mapping
L cycle-values target-peak 100 250 400 800 1000 1500 2500
k add target-peak 50
j add target-peak -50
l show-text ${target-peak}

As for the dim overlay (OSD) components (which includes the OSC, subtitles etc) the general effect can be seen by adjusting target-peak higher, for example. With HDR output this is generally due to a mess that is "Your white is no longer white in HDR", which is also discussed in ITU-T report BT.2408-3.

In this document, if you look at table 1 - "Nominal levels for PQ and HLG production", it gets explained that the "HDR Reference White" (aka "Graphics White") is now at 203 nits. Thus a standard 100 nit SDR graphics signal (which is what the on-screen overlays such as subtitles or controls would be) would have to be boosted towards the graphics white brightness.

That said, whether this is actually needed or not will heavily depend on various parameters. I seem to have previously been able to replicate grey overlays by just enabling HDR output, but when I just tried to re-test a brightness-boosting PR (#7490) it all seems white enough. Seems to depend on the position of the moon, among other things...

In any case, it'd be nice if someone with the "grey on-screen overlays" issue active could check out that proof-of-concept code and say if the whites at the very least are now properly white (while blacks have of course become dark grey since it just dumbly boosts brightness).

agyild commented 4 years ago

As for the dim overlay (OSD) components (which includes the OSC, subtitles etc) the general effect can be seen by adjusting target-peak higher, for example. With HDR output this is generally due to a mess that is "Your white is no longer white in HDR", which is also discussed in ITU-T report BT.2408-3.

In this document, if you look at table 1 - "Nominal levels for PQ and HLG production", it gets explained that the "HDR Reference White" (aka "Graphics White") is now at 203 nits. Thus a standard 100 nit SDR graphics signal (which is what the on-screen overlays such as subtitles or controls would be) would have to be boosted towards the graphics white brightness.

That said, whether this is actually needed or not will heavily depend on various parameters. I seem to have previously been able to replicate grey overlays by just enabling HDR output, but when I just tried to re-test a brightness-boosting PR (#7490) it all seems white enough. Seems to depend on the position of the moon, among other things...

In any case, it'd be nice if someone with the "grey on-screen overlays" issue active could check out that proof-of-concept code and say if the whites at the very least are now properly white (while blacks have of course become dark grey since it just dumbly boosts brightness).

Instead of boosting can't we have something simple and stupid like sub-color? Where 1.0 gets mapped to maximum approximate white point. I don't know the current behavior but it should be simple to implement. Just get the maximum white point value at startup and multiply it with subtitle and overlay color multipliers and finally send the signal.

jeeb commented 4 years ago

Yea, I've had discussions on this, and I think the next attempt will not attempt to boost, but rather just adjust the adjustment back from linear space to PQ/HLG/whatever.

AstralStorm commented 4 years ago

Also add the control for reference SDR white point. We've discussed it in #4248 - with name sdr-target-peak. But you raise a good point, that the reference defaults are different.

Akemi commented 3 years ago

since this question was already discussed and some action were taken, i will close this. if there is still an issue not addressed here please open a new issue.