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

    • Official Post

    smp that code was tested on AW, RK, RPi and AML and it works without issue. It allows to actually skip frames - for example, when you have 4k@30 output and 60 fps video (not really useful, but anyway). Code is otherwise transplanted from ffmpeg codec.

    It can be that frames are mistakenly marked as broken or that Kodi wants to drop frames for some reason.

    Can you test which part is responsible for your issue? First part is pVideoPicture->iFlag line, second part is if clause and third is rest of the code.

    Quote from jernej

    Can you test which part is responsible for your issue? First part is pVideoPicture->iFlag line, second part is if clause and third is rest of the code.

    Playback fails if I only use the first part:

    Code
      pVideoPicture->iFlags |= m_pFrame->data[0] ? 0 : DVP_FLAG_DROPPED;

  if (m_codecControlFlags & DVD_CODEC_CTRL_DROP)
  {
    pVideoPicture->iFlags |= DVP_FLAG_DROPPED;
  }

    First things first: I don't use libreELEC but I came across this thread when searching for HDR on intel nuc with Kodi.

    Maybe this is useful to someone, I think a success report can't hurt:

    HDR works perfectly for me when using the drm-tip kernel branch from freedesktop (drm-tip - DRM current development and nightly trees) and applying the kodi patches from lrusak's branch (Commits · lrusak/xbmc · GitHub) on my Samsung TV (RU8009) with a NUC8i5BEH.

    The only issue currently seems to be the frame drop commit, as mentioned by smp. As everyone else noticed, this breaks DRM on intel entirely. Removing the offending line fixes things neatly.

    Code
    pVideoPicture->iFlags |= m_pFrame->data[0] ? 0 : DVP_FLAG_DROPPED;

    Thanks to everyone who made this possible ( lrusak, smp, ...)!

    Edit: I can also confirm the subtitle issues described somewhere earlier in this thread. The subtitles are either a red stretched image of the film (PGS subtitles) or just a white bar instead of text (ASS subtitles)

    Edited once, last by Deathcrow (April 18, 2021 at 9:04 PM).

    Quote from Deathcrow

    subtitle issues described somewhere earlier in this thread

    This branch does not have that subtitles issue. But I'm not sure that it will work on anything other than Gemini Lake.

    Quote from Deathcrow

    HDR works perfectly for me when using the drm-tip kernel branch from freedesktop

    5.12 will work too. LSPCON HDR support was finally merged into kernel 5.12.

    Edited 2 times, last by smp (April 18, 2021 at 9:57 PM).

    Quote from smp

    5.12 will work too. LSPCON HDR support was finally merged into kernel 5.12

    This is great news! Linux 5.12 onwards will support Intel Kaby Lake graphics through to current. My NUC8i3 should be ok. I can now replace my NUC5i3.

    The burning question: When will we see LPSCON HDR support in an official LibreElec release? LibreElec 11, I guess ?

    I’ll definitely try one of the unofficial patched LibreElec 10 versions with HDR in coming days. Running Win10 and Kodi 19 on my NUC8 is horrible!

    Quote from smp

    I'd like to hear a valid technical reason why bitstreaming is supposed to be better than decoding to LPCM. Since Kodi can decode all known HBR audio formats and send LPCM 7.1 over HDMI I don't see a single good reason why anyone should bother with passthrough.

    Kodi (and every other consumer software audio player) cannot decode Dolby Atmos to more than 7.1 and cannot place Atmos objects in their mixed locations in 3D space. This is also true for DTS:X. The only way to decode Atmos and DTS:X correctly is via HDMI pass-through to an AVR or AV Processor with an Atmos or DTS:X decoder onboard.

    Quote from smp

    What is the advantage of bitstreaming the audio vs.sending the decoded LPCM to AVR? Just trying to understand why people care so much about audio passthrough. I'd like to hear a valid technical reason why bitstreaming is supposed to be better than decoding to LPCM. Since Kodi can decode all known HBR audio formats and send LPCM 7.1 over HDMI I don't see a single good reason why anyone should bother with passthrough.

    Two reasons mainly :

    1. Spatial audio like Dolby True HD with Atmos and DTS:x can't be decoded to PCM without losing the height information - they need to be bitstreamed with passthrough for the extensions to be decoded by an AVR alongside the spatial metadata. If you decode in Kodi you end up with just straight 5.1 or 7.1 - rather than 5.1.2, 5.1.4, 7.1.2, 7.1.4, 9.1.2 etc. you'd get with a receiver fed a bitstream which contains additional audio content and additional object metadata etc.

    2. When you bitstream even non-spatial audio, you still pass through additional metadata alongside the audio - containing information like Dialogue Normalisation values, Line/RF mode compression, Centre and Surround downmix levels, Lt/Rt vs Lo/Ro downmix, original mastering information etc. etc. These all provide additional information that can inform processing in the AVR that is just not present with PCM 5.1/7.1. If you output PCM 5.1/7.1 the receiver doesn't receive this metadata. In some situations this may not be an issue - but if you want to do any dynamic range processing, any down- or up-mixing etc., or want to follow the Dolby spec properly, then PCM won't help.

    dolby-metadata-guide.pdf

    (The above talks about both Dolby E and Dolby Digital - but gives a good overview of the use of metadata)

    In some ways you can think of some of the DD metadata as a bit like the HDR10 metadata that is used with HDR video - it provides the output device with more information than just the picture or audio samples that let output devices optimise things based on information from the person who mastered that content.

    Edited once, last by noggin (April 20, 2021 at 8:21 AM).