Intel true 10bits/HEVC/HDR support... ?

    Quote from chewitt

    The GBM/V4L2 pipeline has probably been actively used on about 10% of the overall range of x86_64 hardware that users probably have. Some of that percentage will be low-risk, but we're expecting a fair number of quirks to surface. So you might be in a rush to use an "official" image instead an otherwise working fine "community" image, but LE10 already impacts 85% of our userbase (RPi) so Generic is in the queue and will have its day (along with the likely end of nVidia support) but some more elapsed time is a good thing. We're not in a rush.

    It‘s still sad, but I understand your line of reasoning.

    Most likely I will use both. The official LE10 release for daily use and the community release mainly for testing. However if it‘s mature enough I would use it daily.

    • Official Post
    Quote from Raven

    Why won't it make it to the LE10 builds? I'm happy to test but in the end I prefer to go back to the original releases and follow their update cycle instead of relying on SMP. Would be a shame to consider replacing this NUC (7i5) if if it has the ability to work but not with the official build.

    It's less about LibreELEC and more about Kodi. Kodi 19 is already in a release cycle so that means no new features and only bug fixes. So that means now that the Kodi 20 development window is open it is possible to get it merged in. I don't spend a lot of time on this though as it's very consuming and requires a lot of work.

    So Kodi 20 is aimed for LibreELEC 11 which may gain x86 HDR support if I merge my work. If people want to take these patches and create their own builds that's possible also. They can also backport the patches to LE10 if they self build.

    Quote from lrusak

    It's less about LibreELEC and more about Kodi. Kodi 19 is already in a release cycle so that means no new features and only bug fixes. So that means now that the Kodi 20 development window is open it is possible to get it merged in. I don't spend a lot of time on this though as it's very consuming and requires a lot of work.

    So Kodi 20 is aimed for LibreELEC 11 which may gain x86 HDR support if I merge my work. If people want to take these patches and create their own builds that's possible also. They can also backport the patches to LE10 if they self build.

    Well LE10 could have ditched x86 if they just said sorry no to nvidia users.

    Quote from chewitt

    because LE10 still uses ye olde Xorg for the Generic image and all these patches are aimed at the GBM/V4L2 pipeline we are not (yet) using. Until we make the switch, community created images are the well-proven approach to testing things.

    Thanks for your explanation.

    So basically all x86 hardware doesn't support HDR until LE10.2 or probably L11/K20. So it's either use the Windows version or these community builds or Rpi4

    Quote from smp

    Yes, Tvheadend that was compiled for X11 version of LE doesn't work.

    I compiled Tvheadend 4.2 and 4.3 that will work with my builds.

    tvheadend42

    tvheadend43

    I did a bit more testing with the supplied tvheadend. I notice Deinterlacing is not available when using your build, most likely because it is not using VAAPI anymore. Is there a work-around for this ? Watching Live TV without deinterlacing is something which is a deal-breaker (too) - even more so than the lack of HDR :)

    I did the test on the NUC6 for this, which I never use before, so it is possible it is related to the NUC6 - rather than your build.

    I also ran some tests on my NUC8i5BEH with the test version from post #502.

    My TV reports that it receives an HDR signal. That’s the good part. ;)

    But at the location on the screen where the subtitles should be, is a bar which contains a stretched version of the running movie but only the red portion. Looks kinda weird.

    Quote from lejose

    Deinterlacing is not available when using your build

    Switch off "Allow using DRM PRIME decoder" and VAAPI deinterlacing will be available. There is no other way at the moment.

    Quote from Deezle

    But at the location on the screen where the subtitles should be, is a bar which contains a stretched version of the running movie but only the red portion.

    Yes, I can also reproduce this on my Gemini Lake box. An issue with subtitle rendering.

    Quote from smp

    Yes, I can also reproduce this on my Gemini Lake box. An issue with subtitle rendering.

    Confirmed - I have the MSI Cubi N 8GL with Gemini Lake Pentium Silver N5000, so I am also dipping in to try out these builds from time to time. This artefact is not present in the regular x86 LE 10.0 beta 1 build here... LibreELEC (Matrix) 10.0 BETA1 – LibreELEC

    I assume this bug is probably specific to the HDR adaptions, although it is seen when playing 4K HDR as well as regular 1080p Blu-ray rips with subtitles.

    Edited 2 times, last by S80_UK: corrections (March 28, 2021 at 5:14 PM).

    Is there any update on a 10-bit replay path, 2160p60Hz output and/or 4:2:2 or 4:2:2 support?

    Last time I trialled the Intel HDR route it was still 8-bit RGB only with an HDR EOTF ?

    On Gemini Lake 2160p60Hz is only possible with RGB 8-bit (default), YCbCr 4:4:4 8-bit (with a driver hack).

    I'm not sure if YCbCr 4:2:0 12-bit could be enabled with a hack or otherwise. 4:2:2 is not supported by the driver.

    It is possible to enable GPU dithering for 8-bit modes (with a driver hack). It certainly eliminates the banding on my test videos and looks ok to me.

    chewitt .. quick question, i saw this on the LE blog "We are pretty confident RPi4 users will like the update since it brings HBR audio and initial HDR video support" .. what exactly does initial support mean?

    So has anyone done "proper" passthru audio testing of the build in 502? Like does it finally fix the split second audio drop that occurs every few mintues?

    • Official Post
    Quote from pletopia

    chewitt .. quick question, i saw this on the LE blog "We are pretty confident RPi4 users will like the update since it brings HBR audio and initial HDR video support" .. what exactly does initial support mean?

    So has anyone done "proper" passthru audio testing of the build in 502? Like does it finally fix the split second audio drop that occurs every few mintues?

    Initial support means: it is the first time someone coded HBR audio for the latest RPi4 codebase (Linux 5.10+) .. not that anyone is planning to rewrite it but as with all first implementations there are likely some corner cases and issues to find. There have already been some fixes and bits which are tested and then pushed upstream. So no idea what you mean with the pithy "proper" comment. The work is being done by a group of people who care deeply about getting it right and there's been a substantial amount of testbench and people testing so it's not some "hey mum, look we make sound" half-arsed exercise. I've no idea what "the build in 502" refers to. You can look at GitHub commits if you want to track the status of development.

    Quote from pletopia

    chewitt .. quick question, i saw this on the LE blog "We are pretty confident RPi4 users will like the update since it brings HBR audio and initial HDR video support" .. what exactly does initial support mean?

    So has anyone done "proper" passthru audio testing of the build in 502? Like does it finally fix the split second audio drop that occurs every few mintues?

    Is this not a bit off topic for this thread?

    Quote from pletopia

    chewitt .. quick question, i saw this on the LE blog "We are pretty confident RPi4 users will like the update since it brings HBR audio and initial HDR video support" .. what exactly does initial support mean?

    So has anyone done "proper" passthru audio testing of the build in 502? Like does it finally fix the split second audio drop that occurs every few mintues?

    Off topic - but the initial support I've seen for HDR on the Pi 4B means that it detects an ST.2084/PQ or ARIB-B67/HLG EOTF flagged (i.e. HDR10 or HLG) in a video file and correctly flags this over HDMI.

    However at the moment it doesn't correctly detect and/or flag Rec 2020 video - so Rec 2020 content is output flagged as Rec 709 (or not flagged as Rec 2020). I've not been able to check whether a Rec 2020 or Rec 709 YCbCr->RGB conversion matrix is used for Rec 2020 video (They aren't the same)

    At the moment I believe video output is restricted to RGB 8-bit too - so no 10-bit replay path yet.

    So you get the correct EOTF flagged, but not the correct Colour Gamut, and with 8-bit not 10-bit or 12-bit output.

    It's very early days - and the Pi Developers work through things methodically to deliver the best results they can with their available effort.

    Quote from smp

    On Gemini Lake 2160p60Hz is only possible with RGB 8-bit (default), YCbCr 4:4:4 8-bit (with a driver hack).

    I'm not sure if YCbCr 4:2:0 12-bit could be enabled with a hack or otherwise. 4:2:2 is not supported by the driver.

    It is possible to enable GPU dithering for 8-bit modes (with a driver hack). It certainly eliminates the banding on my test videos and looks ok to me.

    Good news that 2160p60 is now supported.

    YCbCr in 4:2:0 10-bit or 12-bit would be a good route to full 10-bit HDR output I guess. Dithering is a compromise that adds noise to hide banding. (Is the dithering done at output frame rate or source frame rate?)

    Edited once, last by noggin: Merged a post created by noggin into this post. (March 31, 2021 at 8:53 AM).

    • Official Post
    Quote from smp

    On Gemini Lake 2160p60Hz is only possible with RGB 8-bit (default), YCbCr 4:4:4 8-bit (with a driver hack).

    I'm not sure if YCbCr 4:2:0 12-bit could be enabled with a hack or otherwise. 4:2:2 is not supported by the driver.

    It is possible to enable GPU dithering for 8-bit modes (with a driver hack). It certainly eliminates the banding on my test videos and looks ok to me.

    I'm not really sure about this. Last time I tested my gemini lake hardware enabled 12bit output.

    Code
    [  731.176577] i915 0000:00:02.0: [drm:intel_dump_pipe_config] [PLANE:39:plane 2A] fb: [FB:159] 3840x2160 format = XR30 little-endian (0x30335258), visible: yes
...
[  731.176130] i915 0000:00:02.0: [drm:intel_hdmi_compute_config] picking 12 bpc for HDMI output (pipe bpp: 36)