RPi3 hangs while trying to play HEVC 10bit on Libreelec 10 test builds

  • Hi Libreelec,

    I have been using the latest test builds from Librelec from the Index of / page.

    As of the moment of this writing, I'm still unable to play ANY hevc 10bit (up to 1080p) file.

    With Libreelec 9 virtually everything I threw at my Rpi3b+ played successfully using a software decoder

    Why Librelec 10 cannot play HEVC 10 bit (up to 1080p) anymore?

  • LibreELEC 9 (and earlier) contained a GPU accelerated HEVC decoder - this hasn't been ported yet to the new graphics stack of LE 10.

    so long,

    Hias

    Thanks for replying Hiassoft.

    I believe I saw your name on a changelog a couple of days ago. Assuming that you're an RPi dev I'd like to ask you:

    is there a roadmap until this implementation is done? or at least an estimative?

    Please, let me know.

  • Sorry, I can't give an ETA.

    Current priority is to get the hardware video decoders into shape (there are still some bugs to iron out), after that the HW decoder developer may have time to look into RPi3 HEVC decoding again. But that won't be an easy task, lots of things have to be changed so this can take some time.

    so long,

    Hias

  • Sorry, I can't give an ETA.

    Current priority is to get the hardware video decoders into shape (there are still some bugs to iron out), after that the HW decoder developer may have time to look into RPi3 HEVC decoding again. But that won't be an easy task, lots of things have to be changed so this can take some time.

    so long,

    Hias

    I'm under the impression that RPi2/3 models are becoming too much of a hassle to be maintained.

    Hope I am wrong. But what you said sounded a lot like backporting something too advanced to a dying model

    Which will be sad. Because I haven't purchased a Rpi4 because my Rpi3 did playback 1080p HEVC 10bit (software decoding) using Librelec 9.

    I will only buy another Rpi model when they release a version with AV1 hardware support.

    I will revisit this thread in two months' time.

    Thanks for replying to it.

  • Recent focus has been on getting RPi4 working as in many areas this is more complex and provides a superset of the functionality needed for older Pi models. Now that many of the big-ticket issues are resolved or have progressed (and the dynamics of the all-new code are starting to be much better understood) the attention can shift back towards RPi2/3 devices where changes are needed. There is desire/intent to make HEVC work on the new stack too, but it's entirely new code and it works very differently to the older stack, and people forget that it took several years of progressive tinkering to get it as good as it currently is on the older stack. NB: There's nothing to stop you (and many other RPi3 users) continuing to use LE 9.2.

  • Hi chewitt

    A long time has passed and I'm wondering what's the real status of software HEVC playback to return on the RPI3 in Libreelec future builds?

    Please let us know. I've read here and there that it isn't likely to return.

    Regards,

    H.

    PS: what's the official Matrix 20 thread. Is there one?

  • RPi3 hardware deinterlace is being actively worked upon and public testing of code should happen soon. Support for 3D is something that can probably be done and one of the Pi Devs has a 3D TV so while it's niche and not a priority for the Foundation, personal interest will probably make it happen eventually. The advantage these "missing" features have is, they also benefit RPi4 support. Software HEVC optimisation for RPi3 is a little different and IMHO unlikely to be reimplemented. One objective of the new video stack is to get everything upstream to make RPi support consistent and better in all distros: previous HEVC support only ever worked in LE and OSMC because we were prepared to add 50,000 LOC patches that normal distros with mature package/patching policies refused. HEVC is probably not technically impossible to do in the new video pipeline, but it would (again) need large unorthodox changes that would never be accepted upstream, and the changes need a ground-up rewrite not adaptation of the previous approach so it's a considerable effort. Meanwhile RPi4 has native hardware decode that works nicely, and while the code is not all upstream yet, ffmpeg is the main missing bit and that effort will start sooner than later. Forcing users to upgrade to profit the Foundation has never been an objective with any of the Pi developers, but upgrading to an RPi4 is the simple and obvious option for anyone who needs HEVC support (and you get 4K, HDR, HBR audio included too).

    Matrix is K19/LE10 and there is a release thread. K20 is in a pre-Alpha state so there is no LE11 thread at this time.

  • Thank for replying chewitt

    I already suspected that this was bound to happen. I even mentioned earlier this year. This is sad news. But it opens another questions regarding the future of the Raspberry Pi and software decoding.

    And what about AV1 support? Since there isn't any hardware support available. Will there be software decoding on the RPI3/4?

    I've just installed the latest available nightly build for my RPI3. And I know there was a lot of improvement made within DAV1D. I've also read in the changelog on the Libreelec GitHub that the latest Dav1d version made into Libreelec.

    That being said. I haven't seen any gains on the RPI3. Not even on 720p AV1 video files.

    Does this mean that there will never be AV1 software decoding support on the Raspberry Pi 3/4 due to the impossibility of being accepted upstream?

    If that's the case. It will be pretty hard to wait until 2023 to see a RPI device with AV1 hardware decoding capabilities.

    Regards,

    H.

  • LE/Kodi already supports fallback to software decode for unsupported [in hardware] codecs - it's how we play HEVC on RPi3 today. I have no expectations performance-wise that AV1 would be any different to HEVC on RPi3. `RPi4 is also missing hardware support but has considerably more ARM grunt so will probably fare better, I haven't personally tested but suspect it can handle lower-bitrate AV1 (1080p, forget about 4K) which reduces the likelihood of anyone investing time/effort in software optimisation. I'm sure Pi Foundation will consider adding an IP block to their next silicon generation if it becomes a mainstream thing in the broadcast world.

  • Thanks for replying chewitt

    I was referring to AV11080p software decoding. Can you tell us if the latest Dav1D code already reached the ffmpeg that you guys use to build Kodi upon?

    If you look into the changelog there is some ARM NEON optimisations made. That used to meant improvements to the Raspberry Pi. Maybe another dev can chime in here?

    I don't expect AV1 will become a thing in the broadcast world. It wasn't meant to be. VVC is the next thing in the broadcast world. But that's years away from us. But nonetheless I will assume that the Pi Foundation won't be negligent to the point of ignore AV1. It is for all intent and purposes the defacto NETVC standard.

    Only this month of September was announced three new "Stick devices" with AV1 hardware decoding capabilities from Amazon, Roku and Xiaomi. I'm pretty sure Google is about to launch a revamped Chromecast that will also support AV1.

    And since I really believe in the experience of running Kodi on a Raspberry Pi instead of a Stick I would like to ask you a final question.

    Since you were talking about raw CPU power in order to playback AV1 10BIT up to 1080p How well does Libreelec runs on the Raspberry Pi 400?

    Regards,

    H.

  • I asked Pi devs. It's hard to find AV1 media (not 4K) but last time they did somtehing with basic clips RPi4 was handling 720p HD fine and 1080p was borderline but there have been optimisations in AV1 code since which might improve it. RPi3 didn't cope with 720p.

    I've never seen an RPi400 but it's basically a repackaged RPi4 4GB and project stats show RPi4 4GB to be our 2nd most popular device now. I use an 8GB as a daily driver; the RAM size isn't important, over 2GB is fine. Extra RAM is only useful if you plan to run other apps/containers under Docker.