Kodi Community Forum - HDR Content Playback

Hello,
please help me understand.
I have some HDR content here. I had a Chromebox previously, and it wasn't able to play it back. It was also acting up, so I got myself RP4, the first I ever owned.
It will play back 4k content, but the colors are all way off, completely washed out. I am playing back on an Epson (non-4K) beamer. I didn't yet try to output Windows Kodi onto the beamer...
If I play the same content on my computer, and mind screens are not HDR, just simple IPS iiyama screens, doesn't matter if in VLC or Kodi under Windows, the colors are all there, very sharp and live everything.
So how come? Am I missing something? Is the hardware missing something? It ain't Kodi I think, since it plays well on Windows.
Thanks

(2019-09-14, 23:52)kosta88 Wrote: [ -> ]Hello,
please help me understand.
I have some HDR content here. I had a Chromebox previously, and it wasn't able to play it back. It was also acting up, so I got myself RP4, the first I ever owned.
It will play back 4k content, but the colors are all way off, completely washed out. I am playing back on an Epson (non-4K) beamer. I didn't yet try to output Windows Kodi onto the beamer...
If I play the same content on my computer, and mind screens are not HDR, just simple IPS iiyama screens, doesn't matter if in VLC or Kodi under Windows, the colors are all there, very sharp and live everything.
So how come? Am I missing something? Is the hardware missing something? It ain't Kodi I think, since it plays well on Windows.
Thanks

VLC and Kodi under Windows will do HDR->SDR conversion (to a degree) and Rec 2020->Rec 709 gamut mapping I believe. This is because these applications on the Windows platform have been coded to take this into account.

The Pi 4B is capable of decoding 4K HEVC 10-bit content - but if this content is in Rec 2020 (i.e. wider colour gamut) and HDR (i.e. wider dynamic range), the Pi 4B currently doesn't do any processing that takes this into account, and I believe it plays it as if it was in the regular SDR Rec 709 (i.e. standard HD) colour space. As a result you get washed out pictures with desaturated colours and a very flat, lifeless look. In this case there is no significant HDR->SDR conversion taking place, and the content is played as if it were SDR with no conversion.

Kodi and VLC have very different video and graphics processing on the Windows and Pi 4B platform (and the Pi 4B is still very new) - so the applications will handle HDR native content very differently.

The Pi 4B is still very 'Alpha' in Kodi terms. The hardware should eventually be capable of outputting HDR content in HDR.

VLC (at least for iOS/tvOS) uses libplacebo for HDR -> SDR conversion. Not sure what VLC does on windows.

https://github.com/haasn/libplacebo

(2019-09-15, 19:14)noggin Wrote: [ -> ]The Pi 4B is capable of decoding 4K HEVC 10-bit content - but if this content is in Rec 2020 (i.e. wider colour gamut) and HDR (i.e. wider dynamic range), the Pi 4B currently doesn't do any processing that takes this into account, and I believe it plays it as if it was in the regular SDR Rec 709 (i.e. standard HD) colour space. As a result you get washed out pictures with desaturated colours and a very flat, lifeless look. In this case there is no significant HDR->SDR conversion taking place, and the content is played as if it were SDR with no conversion.

Kodi on Pi4 (from my tree) does plumb though Rec2020 info to firmware (see here).
And the firmware uses a different colourspace transformation matrix in this case.

Note: this doesn't include the wider range of colours possible with HDR signalling which will come later, but should means Rec 2020 files look okay.

I believe support for this is in LE 9.1.002 (but wasn't in 9.1.001), but it might be worth trying the 9.2 beta 1 just in case it missed that version.

If there's still an issue I'll flag it with the HDMI guy to double check the colourspace matrix is correct.

(2019-09-16, 13:49)popcornmix Wrote: [ -> ]
(2019-09-15, 19:14)noggin Wrote: [ -> ]The Pi 4B is capable of decoding 4K HEVC 10-bit content - but if this content is in Rec 2020 (i.e. wider colour gamut) and HDR (i.e. wider dynamic range), the Pi 4B currently doesn't do any processing that takes this into account, and I believe it plays it as if it was in the regular SDR Rec 709 (i.e. standard HD) colour space. As a result you get washed out pictures with desaturated colours and a very flat, lifeless look. In this case there is no significant HDR->SDR conversion taking place, and the content is played as if it were SDR with no conversion.

Kodi on Pi4 (from my tree) does plumb though Rec2020 info to firmware (see here).
And the firmware uses a different colourspace transformation matrix in this case.

Note: this doesn't include the wider range of colours possible with HDR signalling which will come later, but should means Rec 2020 files look okay.

I believe support for this is in LE 9.1.002 (but wasn't in 9.1.001), but it might be worth trying the 9.2 beta 1 just in case it missed that version.

If there's still an issue I'll flag it with the HDMI guy to double check the colourspace matrix is correct.

Does this mean Rec 2020 content is output flagged as Rec 2020 - so HLG Rec 2020 content will be output Rec 2020 flagged SDR (and as HLG is pretty compatible with SDR should look fine)?

Or is the Rec 2020 tonemap converted to Rec 709 and output flagged as Rec 709?

HDR10 PQ content will look washed out if displayed unconverted in SDR. (Rec 2020 conversion or not) HLG content should look better (as it's backwards compatible with SDR)

I believe the current intention is to convert Rec 2020 tonemap to Rec 709 and output image flagged as Rec 709.
But I think the 2020->709 matrix isn't right. We're looking into that.

A slightly more future intention is for Rec 2020 content to be output flagged as Rec 2020.

The more future intention is also to also output deep colour.

(2019-09-17, 17:22)popcornmix Wrote: [ -> ]The more future intention is also to also output deep colour.

By deep colour do you mean 10-bit RGB/4:4:4 YCbCr (for 2160p30 and below only) and/or 12-bit 4:2:2 YCbCr (for all modes, but particularly 2160p50 and above)

(I'm assuming that 4:2:0 YCbCr 10-bit, which can only be used for 2160p50 and above, is tricky because of the requirement for vertical chroma subsampling?)

(2019-09-18, 08:50)noggin Wrote: [ -> ]By deep colour do you mean 10-bit RGB/4:4:4 YCbCr (for 2160p30 and below only) and/or 12-bit 4:2:2 YCbCr (for all modes, but particularly 2160p50 and above)

Both.

Quote:(I'm assuming that 4:2:0 YCbCr 10-bit, which can only be used for 2160p50 and above, is tricky because of the requirement for vertical chroma subsampling?)

Correct.

(2019-09-17, 17:22)popcornmix Wrote: [ -> ]I believe the current intention is to convert Rec 2020 tonemap to Rec 709 and output image flagged as Rec 709.
But I think the 2020->709 matrix isn't right. We're looking into that.

A slightly more future intention is for Rec 2020 content to be output flagged as Rec 2020.

The more future intention is also to also output deep colour.

I'm running a Pi 4B with LibreELEC (Leia) 9.2 Beta1 from the public downloads page, not a nightly.

Just looked at some Rec 2020 HLG EOTF HDR content and it looks as if the Rec 2020 YCbCr 4:2:0 10-bit content to RGB Rec 709 8-bit playback is doing an at-least-watchable Rec 2020->Rec 709 tone mapping (i.e. it's not totally desaturated as if Rec 2020 RGB primaries are mapped to Rec 709 primaries with no gamut conversion?) The content I have in both HDR10 and HLG flavours IS very saturated though - so I may be mistaken...

**EDIT - think I may be. Manually forcing my TV into Rec 2020 gamut when fed the Rec 709-flagged RGB seems to look 'nearer' **

HLG's EOTF is backwards compatible-ish with SDR Power Law Gamma/BT.1886 EOTFs - so black levels remain OK and ~75% of the luminance range looks OK (brighter areas look a bit like they have have a heavy knee on them rather than clipping)

When I manually force the TV into HLG HDR this seems to do an OK job.

Looking at the same content in HDR10 Rec 2020 with a PQ ST.2084 EOTF, the Pi 4B may be doing some EOTF conversion (as it doesn't look like HDR10 stuff does when played back as if it is SDR) but the tone mapping isn't as good as it is with HLG content (but that may because HLG is just being Gamut mapped not EOTF converted?) It's not as bad as if has been left alone, though it's clearly still 'off'. (Having the same video content in both HDR flavours is useful!) However when I force the TV into HDR10 mode, it's clear that the input isn't native HDR10 as the forced result looks very 'off'

Out of interest - is the approach for Rec 2020 PQ EOTF to Rec 709 BT.1886/Power Law gamma a Scene Light or a Display Light conversion?

I guess there are three things that need to happen - though these may be partially combined :

1. Rec 2020 YCbCr to RGB conversion uses different co-efficients Y = 0.2627R + 0.678G + 0.0593B (Rec 709, Rec 601 and Rec 2020 all have different RGB->YCbCr mappings)
2. If you are outputting Rec 2020 as Rec 709 you need to gamut convert because the Rec 2020 RGB primaries are very different 'colours' to the Rec 709 RGB primaries - as they have a wider colour gamut. You need to decide how you handle 'out of gamut' Rec 2020 colours that can't be accurately carried in Rec 709 gamut video. There are multiple approaches to this.
3. If you are handling HDR10 PQ or HLG HDR but outputting this as SDR Rec 2020 or Rec 709, you have to EOTF convert. This can be combined with 2. if you are outputting a Rec 2020 HDR source as a Rec 709 SDR signal. You have to decide how to handle HDR content that can't be carried within an SDR signal range. Display Light approaches make the SDR version look as close to the HDR version as possible (keeping a look as close to the HDR version as possible), Scene Light approaches try to simulate what an SDR camera shooting the same scene as the HDR camera would have looked like.