[username145]

There is no proper HDR in Intel.

• With the GLES path you only faked HDR with 8 bit. That is even worse than no HDR at all.
  
• Intel has no driver for v4l2, hence no drmprime decoder. The mentioned LE patch does no change this.
  

There is some ongoing work to map VAAPI surfaced to drm: https://github.com/xbmc/xbmc/pull/19142 Leaves the question open if Intel video driver on Linux supports reading out video plane separately.

EDIT: Be my guest and proof me wrong by posting a debug log which shows that an Intel system uses drmprime decoder.

Does that mean these builds are not doing real HDR? https://forum.libreelec.tv/thread/25185-...l-and-amd/ (genuine question, I'm not knowledgeable enough to refute any of your points)

[FernetMenta]

If they do, they are far away from mainline kodi and hold the vaapi patch I mentioned above. Maybe they build from lrusaks fork as mentioned in the discussion: https://github.com/lrusak/xbmc/commit/6c...9f89bb2896

[ryback]

There is no proper HDR in Intel.

• With the GLES path you only faked HDR with 8 bit. That is even worse than no HDR at all.
  
• Intel has no driver for v4l2, hence no drmprime decoder. The mentioned LE patch does no change this.
  

There is some ongoing work to map VAAPI surfaced to drm: https://github.com/xbmc/xbmc/pull/19142 Leaves the question open if Intel video driver on Linux supports reading out video plane separately.

EDIT: Be my guest and proof me wrong by posting a debug log which shows that an Intel system uses drmprime decoder.

Just for testing's sake, i decided to try that pull request applied to current master.
Here's the log when running Intel system/drmprime with it:
https://paste.kodi.tv/yepupozamo.kodi
Video output did work, but all colors were converted to red. (that pull request is pretty old tho and parts of the code have changed since, which might (?) explain the issue). I'm not an expert at all in this field, just wanted to test (and not intending to prove you wrong either).

[smp1]

My LE HDR builds were based on this - https://github.com/lrusak/xbmc/commits/d...fmpeg-bump

[FernetMenta]

Thank for clarification. I summarise: HDR on Intel and AMD systems seem to be possible but require a whole lot of patches, not only to Kodi itself. I don't see any evidence that all those patches will hit their base repos any time soon.

[izprtxqkft]

thanks @FernetMenta in the previous thread i was trying to point that out but i lacked the general terminology needed to convey that "HDR+Linux!=Good" (Currently)

[username145]

So if the the LE nightlies have working HDR for intel and AMD (first post in this thread), has anyone been able to adapt their changes and get it all working on full blown linux operating systems? I unfortunately cannot run LE as I need the flexibility of Arch or Ubuntu, and am saddened by the idea of waiting for Kodi 21 to use HDR.

[fritsch]

So if the the LE nightlies have working HDR for intel and AMD (first post in this thread), has anyone been able to adapt their changes and get it all working on full blown linux operating systems? I unfortunately cannot run LE as I need the flexibility of Arch or Ubuntu, and am saddened by the idea of waiting for Kodi 21 to use HDR.

You did not really read and understand what was said in this thread. There are builds that have 8 bit output with HDR trigger -> Fake HDR. There was another kodi branch linked which requires ffmpeg patches and kodi patches to make it work differently on intel hardware. So what do you want - the green light? Or proper 10 bit HDR?

[username145]

So if the the LE nightlies have working HDR for intel and AMD (first post in this thread), has anyone been able to adapt their changes and get it all working on full blown linux operating systems? I unfortunately cannot run LE as I need the flexibility of Arch or Ubuntu, and am saddened by the idea of waiting for Kodi 21 to use HDR.

You did not really read and understand what was said in this thread. There are builds that have 8 bit output with HDR trigger -> Fake HDR. There was another kodi branch linked which requires ffmpeg patches and kodi patches to make it work differently on intel hardware. So what do you want - the green light? Or proper 10 bit HDR?

Sorry, by HDR I meant proper 10-bit HDR. The LE builds in that thread were based on this branch, which presumably does do proper HDR for intel/AMD. Since the thread mentions those builds are no longer needed, presumably the LE nightlies also do proper HDR for intel/AMD now, so it should be possible to adapt the changes from LE nightlies and have proper HDR in Arch linux as well, right?

[FernetMenta]

Since the thread mentions those builds are no longer needed, presumably the LE nightlies also do proper HDR for intel/AMD now ...

Who said this? LE nightlies don't do proper HDR because too many patches of too many components are required.

and am saddened by the idea of waiting for Kodi 21 to use HDR

I seriously doubt that Kodi 21 will be able to do HDR on Intel/AMD if they release it within the next two years.

[username145]

Who said this? LE nightlies don't do proper HDR because too many patches of too many components are required.

I was under the impression that the builds in this thread were doing proper HDR. The first post in that thread now states that those builds are obsolete as LE nightlies have the necessary changes.

So is it correct to say that proper HDR for Kodi for intel/AMD on linux is not implemented anywhere yet?

[FernetMenta]

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.

[username145]

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

[FernetMenta]

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.

[chewitt]

Right now there are pieces missing in the kernel. Pieces missing in mesa. Pieces missing in Windowing systems. Pieces missing in FFMpeg. Pieces missing in Kodi. One of the main blockages is for "Linux graphics" personages to agree on how colourspace and colorimetry are communicated between userspace which sees the media being played, and the kernel which can see the internal and output capabilities of hardware; both the display device (e.g. TV panel) and the decoding and rendering pipeline. There are passionate arguments for everything beind done automagically in the kernel, and equally for the kernel to be more subservient to userspace which has better visibility on the media requirements. TV manufacturers have done a good job of dumbing down their messaging on HDR for consumers who want the latest tech, leading to general ignorance on how insanely complicated the task actually is. HDR is not about "just passing through" some extra data and picking a 4K resolution/refresh-rate. HDR support is about evaluating the large number of variables presented by TVs that don't support all colourspaces and display hardware that lacks certain colourspace and colorimetry options, and player apps that don't recognise certain formats, and media designed for proprietary license schemes: and then picking the least-worst compromise to present something nice-looking to the user (while ensuring HDR mode is triggered on the TV else it's not believed to be HDR). All devices that "support HDR" today are choosing compromises that hopefully get the best from their hardware. Kodi will get there too, but aiming to support HDR on a very wide range of hardware and OS options inherently complicates an already complicated challenge. Hopefully there's a good result from that RedHat sponsored meeting next month, because until there's a common technical direction for everyone to start working towards, Linux HDR support won't mature.