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

  • I just tested on my workstation using GLES/GBM with dma-heaps and all seems fine, this is with an AMD GPU though.

  • I tried to increase CMA to 512 but it didn't fix the issue.

    I tested only on Gemini Lake board.

  • 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 [email protected] 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.

  • lrusak

    There is also another issue - this commit completely broke the playback on DRM PRIME, at least on Intel. I tested with pure Kodi master, no WIP HDR stuff involved.

    Kodi master doesn't work with DRMPRIME on intel :)

  • 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;
      }
  • 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;
      }

    This does actually two different things. Can you please each one separately?

  • I'll have to update the VAAPI patch to work with these changes. It's a simple fix but not sure if I'll have time today.

  • This does actually two different things. Can you please each one separately?

    It fails with this part:

    Code
    pVideoPicture->iFlags |= m_pFrame->data[0] ? 0 : DVP_FLAG_DROPPED;
  • smp Fix is to also consider m_pMapFrame - this will be in @lrusaks updated VAAPI patches. In the mean time, you can just remove that line.

  • There is an issue with VP9 10-bit videos and Intel media-driver. It affects both X11 and GBM. I reported it here. Media-driver person say it is a Kodi issue.

  • 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 ().

  • 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.


    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 ().

  • 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!

  • 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.

  • 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 ().