[halfproxy]

If LE nightlies are built from their master branch, the generic built can only do fake HDR via GLES because it pulls kodi from the official kodi repo: https://github.com/LibreELEC/LibreELEC.t...package.mk

Either the LE guys don't know better or they deliberately fool users.

Even taking into account the patches applied?

https://github.com/LibreELEC/LibreELEC.t...di/patches
https://github.com/LibreELEC/LibreELEC.t...eg/patches

Yes, those builds only do 8-bit fake HDR.

Do you know if there have been any changes in this area for v21?

[fritsch]

Even taking into account the patches applied?

https://github.com/LibreELEC/LibreELEC.t...di/patches
https://github.com/LibreELEC/LibreELEC.t...eg/patches

Yes, those builds only do 8-bit fake HDR.

Do you know if there have been any changes in this area for v21?

Not Linux GLES/GL path.

[halfproxy]

Yes, those builds only do 8-bit fake HDR.

Do you know if there have been any changes in this area for v21?

Not Linux GLES/GL path.

Do you know if there is a GitHub issue (or issues) we can follow that track the progress of real HDR on x86 linux? I searched but there are quite a few results, with most of them going way over my head.

[htpcero]

I noticed that the kodi 21 flatpak (running on intel N100) now shows an HDR setting, that can be turned on an off, and HDR10 movies get an hdr10 label. I tried to test with a few old hdr samples I had and the hdr setting seems to make a small difference/improvement when turned on, in colors and gray levels. Not sure if it's more of a placebo effect or not

[htpcero]

FWIW, the official flatpak build is using GL not GLES, so no HDR despite showing the toggle and detecting the TV HDR support.

This is on recent intel hardware, N100 platform, ubuntu 23.10. Samsung 2021 TV with hdr10, hlg support.

I tried buiding a flatpak with GLES enabled (otherwise the same as the official flatpak), the build succeeded and installed fine, I ended up doing this twice. The first try (built on the N100) was OK for SDR content but would crash when trying to play anything HDR. The second try, built on an i9 desktop and installed on the n100, was successful. Stable, plays any content as normal, and the TV detects HDR for HDR10 and HDR10+ content.

Test HDR videos that used to play with washed out colors and little contrast now show saturated colors and are darker, with much deeper contrast.

Finally, Kodi supporting HDR on Linux! Thanks devs!

[halfproxy]

FWIW, the official flatpak build is using GL not GLES, so no HDR despite showing the toggle and detecting the TV HDR support.

This is on recent intel hardware, N100 platform, ubuntu 23.10. Samsung 2021 TV with hdr10, hlg support.

I tried buiding a flatpak with GLES enabled (otherwise the same as the official flatpak), the build succeeded and installed fine, I ended up doing this twice. The first try (built on the N100) was OK for SDR content but would crash when trying to play anything HDR. The second try, built on an i9 desktop and installed on the n100, was successful. Stable, plays any content as normal, and the TV detects HDR for HDR10 and HDR10+ content.

Test HDR videos that used to play with washed out colors and little contrast now show saturated colors and are darker, with much deeper contrast.

Finally, Kodi supporting HDR on Linux! Thanks devs!

Just a few posts above yours it is stated that Kodi does *not* properly support HDR on x86 linux. I'm not sure why everyone here and over at LibreELEC forums ignores these statements from members of the Kodi development team and continue reporting how well it works. The fact that a TV successfully switches to "HDR mode" doesn't mean it's displaying the colors properly.

[htpcero]

I get the point (I think) about the current implementation, how it misses 2 of the 10 bits, how it's not fully there yet. Even so, the result looks really well, to the point that when consuming content in kodi the hdr version looks *a lot* better than the non hdr version, I just did a few comparisons (untrained eyes); between the tv switching modes and whatever information kodi is passing, the result is very noticeably better than SDR. That may explain the excitement in the libreelec community and elsewhere.
Noticed some work in ffmpeg on dynamic HDR support over the last few months - so I guess what we have is a start and the future looks promising for hdr in linux.

[smp1]

I'm not sure why everyone here and over at LibreELEC forums ignores these statements from members of the Kodi development team

HDR for x86 in Kodi is the work of one developer (Lucas Rusak). If you look at his HDR/GLES-related commit history, you will see that those statements about "8-bit fake HDR" are nonsense. 
Also, 10-bit video displayed in 8-bit would have looked bad with tons of banding artifacts, no need to look at the code to figure that out.

[fritsch]

I'm not sure why everyone here and over at LibreELEC forums ignores these statements from members of the Kodi development team

HDR for x86 in Kodi is the work of one developer (Lucas Rusak). If you look at his HDR/GLES-related commit history, you will see that those statements about "8-bit fake HDR" are nonsense. 
Also, 10-bit video displayed in 8-bit would have looked bad with tons of banding artifacts, no need to look at the code to figure that out.

Nonsense - that's a very good technical argument, awesome even. If you are happy, stay happy. If you want to see the details check the simple line for the final visual that is created on the GLES platform, which is - ouh noes - 8 bit. If you talk about some private fork somewhere with v4l patches for intel -> different story, nothing mainline.

[smp1]

You are contradicting your own post from over a year ago. GLES does not process the video data.

[fritsch]

You are contradicting your own post from over a year ago. GLES does not process the video data.

That's where things suddenly get problematic and where all the confusion is coming from, see also the replies. While GBM path is prepared / can do things - it only works for devices that have their own video plane (see the explicit opening of a gui plane and a video plane), which intel on x86 is not. Exactly this won't work for Intel and which is why I said: without a patched v4l2 - the final GUI mode is still 8 bits.

You can still see this, when you open a simple Debug Log. And yeah - the poster before me told it: When I build with GLES instead of GL - I get HDR ... and that's yeah, exactly the fake code ... which is in GLES and not in GL.

See: It's okay for me. People seem not to realize / value wise that their 8 bit values on their 8 bit visual (not color corrected by any tone mapping or shader) are then color processed by TV's HDR functionality are looking good enough for them, while the 10 bit precision is gone.

We can also go back to guessing. You seem to like that:
If I am wrong, please tell me - why people get suddenly 10 bit HDR output with GLES - while this should not be involved at all.

[fritsch]

Could you please post a Debug Log of yours, please? Let's see if kodi's GUI gets a 10 bit overhaul somewhere ;-)

[smp1]

Could you please post a Debug Log of yours, please? 

debug log

[fritsch]

Good - the first thing I realize is: It opens 10 bit precision, but - but ARGB, with each color being 10 its, Alpha being 2 bits.
Second thing: GBM is used and when the LinuxRendererGLES starts rendering, it is put into 10 bit mode
Third thing:

2024-05-01 03:22:31.452 T:690     debug <general>: LinuxRendererGLES::Configure: HDR passthrough: on
2024-05-01 03:22:31.459 T:690     debug <general>: GLES: using scaling method: 18
2024-05-01 03:22:31.459 T:690     debug <general>: GLES: using shader: gles_convolution-6x6.frag
2024-05-01 03:22:31.463 T:690      info <general>: GLES: Selecting multi pass rendering
2024-05-01 03:22:31.463 T:690     debug <general>: GLES: Requested render method: 0
2024-05-01 03:22:31.463 T:690      info <general>: GLES: Selecting YUV 2 RGB shader
2024-05-01 03:22:31.463 T:690     debug <general>: GLES: using shader format: 10
2024-05-01 03:22:31.463 T:690     debug <general>: GLES: using tonemap method: 0
2024-05-01 03:22:31.464 T:690     debug <general>: GLES: using shader format: 10
2024-05-01 03:22:31.464 T:690     debug <general>: GLES: using tonemap method: 0
2024-05-01 03:22:31.466 T:690     debug <general>: CRenderManager::Configure - 4
2024-05-01 03:22:31.467 T:690   warning <general>: CLinuxRendererGLES::UpdateVideoFilter - chosen scaling method 18, is not supported by renderer
2024-05-01 03:22:31.467 T:690      info <general>: GLES: Selecting single pass rendering

Here we see two things: We see a YUV 2 RGB shader. So the Video planes are transformed to RGB here as well. Hopefully this results in "proper" RGB values, where no tone mapping is applied (can be seen above, not the case) but also the inverse linearization that we do to reach proper SRGB opens a blackbox path. Remember what you have on the plane here (and yeah it's the GUI plane) should be "compatible" to the tone mapping your TV is going to do. So our Shader applies the BT2020 conversion, so we have one time processed YUV 2 RGB color transformation.

So in ideal case, you end up with a RGBA plane holding your high precision values. I have no idea what your TV reports ... the hope is though - that the combination of "Light Metadata" + RGBA planes properly output / converted by the intel drm driver ends up in a nice combination.

But I see one point where I was wrong: The visual seems to be "large" enough. For the rest of the chain ... it's still questionable to me if that's color correct enough.

Actually it would be great if VAAPI would be capable to import the decoded frames via dmabuf and gbm directly and the GLES shader would only really be used for the GUI. This video plane approach i don't see yet in the code.

Thanks for posting.

[smp1]

The initial implementation for Intel actually used direct to plane rendering. But it never made it to mainline Kodi:
https://forum.libreelec.tv/thread/13738-...post154634
https://forum.libreelec.tv/thread/13738-...post154666