LinuxRendererGLES: enable HDR passthrough for HDR videos with incomplete(?) metadata info #24160
Conversation
| @@ -132,7 +132,6 @@ bool CLinuxRendererGLES::Configure(const VideoPicture &picture, float fps, unsig | |||
| // setup the background colour | |||
| m_clearColour = CServiceBroker::GetWinSystem()->UseLimitedColor() ? (16.0f / 0xff) : 0.0f; | |||
|
|
|||
| if (picture.hasDisplayMetadata && picture.hasLightMetadata) | |||
There was a problem hiding this comment.
I don't think this "fixes" the problem. Allowing incomplete metadata may result in a worse image as the MaxFALL and MaxCLL provide info about the HDR content.
This means that if the encoding contains a valid HDR10 (pq) or HLG flag in the color_transfer then it can switch HDR mode on without any other metadata.
Simply seeing the HDR logo light up on the tv doesn't mean the picture is correct.
Ref:
Static metadata: SMPTE ST 2086 (mastering display color volume), MaxFALL (maximum frame-average light level), and MaxCLL (maximum content light level)
https://en.wikipedia.org/wiki/HDR10
And
MaxFALL/MaxCLL is static metadata required for HDR10 content.
There was a problem hiding this comment.
It can't look worse than any of the tone mapping methods. IMO we'd still want to switch the TV to HDR/BT.2020/HLG.
There was a problem hiding this comment.
Not to mention that DRM PRIME platforms, eg. RPI4 allow switching to HDR mode with those "incomplete metadata" videos. Why this should be different for Intel?
There was a problem hiding this comment.
Even the TV's internal player would switch the TV to HDR mode with those videos. But on Intel PC they are tone mapped to SDR and look horrible.
There was a problem hiding this comment.
This video, for example, doesn't even trigger the tone mapping and it is absolutely unwatchable. With this PR it would switch the TV to HDR mode and looks perfectly fine, same as with TV's internal player.
There was a problem hiding this comment.
Not to mention that DRM PRIME platforms, eg. RPI4 allow switching to HDR mode with those "incomplete metadata" videos. Why this should be different for Intel?
If the behaviour is inconsistent across platforms we should check how other platforms and applications handle it.
If it's expected to be able to just ignore any metadata then so be it but we should investigate more about what the correct behaviour should be.
There was a problem hiding this comment.
In case of HLG streams - they don't even use MaxFALL/MaxCLL so those metadata checks would never allow the TV to switch to HDR. IMO the correct behaviour is to copy the behaviour of TV's internal player which is allow switching to HDR mode without MaxFALL/MaxCLL metadata.
There was a problem hiding this comment.
I also removed metadata checks for tonemapping. HLG streams and HDR10 videos with missing MaxFALL/MaxCLL didn't trigger tonemapping for SDR TVs.
There was a problem hiding this comment.
I was going to suggest removing the check altogether if you hadn't done it already. For Windows, HDR mode is triggered by color_transfer + primaries only. Metadata, when present, is forwarded as is to the TV, it hasn't caused issues that I know of. But it's possible that Windows is interfering in the process.
HLG streams typically don't come with metadata and that's valid. Windows has special handling though because of missing HLG passthrough support, Instead it's converted to PQ with shader and metadata is made up with 1000nits max, value found in many places of HLG spec.
smp79
force-pushed
the
gles-hdr
branch
4 times, most recently
from
c00aad5
to
fc04d6c
Compare
|
It's very strange to me that the changes remove HDR10 metadata passthrough altogether. |
The changes only remove unneeded checks and the leftover code that was used only for those checks. |
|
I know it is a stretch but could this have anything to do with my issue, in which youtube HDR videos refuse to play until I disable HDR? I'm using an intel Arc card...though if I disable use of the Arc, it does play, albeit poorly. |
All I can say is that with this PR VP9 HDR videos that I downloaded from youtube (like this one) would switch the TV to HDR mode. Without this PR they are tonemapped to SDR. Whether or not it has anything to do with your issue I have no idea. |
|
My current struggle seems more to potentially be either with buliding and running Kodi on Arch, or with my intel arc... I ran Libreelec live and managed to get it to switch to HDR, for one video but then no others...lol not sure how to handle that especially since my goal is avoiding the use of the privacy unfriendly google tv install that my new bravia has. I did a build with this patch and it didn't solve my issues, unfortunately. |
|
So youtube HDR playback is still fully broken for me (though I wonder if it's not broken for everyone and everyone just watches youtube on Kodi in SDR), but I found arch is packaging kodi with the gl instead of gles backend...it appears that some if not all vp9 videos, at least when in mkv containers, refuse to playback in HDR mode for me, as well... |
|
@smp79 you think this will ever get merged? I've been building with it locally for a while now, as it fixes all of my trouble with HDR save for issues with youtube and my Arc card...so for vp9 i have VAAPI disabled right now. |
|
Any thoughts on merging this? |
No idea. |
Agree 100%. |
|
can add this patch for kodi20 ? |
Description
This fixes #8322. This also fixed HDR passthrough for all of my HDR videos that didn't switch my TV into HDR mode. Even the HLG sample now switches the TV to HLG HDR mode.
How has this been tested?
Tested on Intel TGL + Samsung 4K TV.
Types of change
Checklist: