RPi3B GPU accelerated H265 decode in LE 10 and future versions

  • There are several reasons:

    a) Kodi no longer supports OMXplayer and MMAL decoding as part of the general move to drop all proprietary codecs to focus on modern kernel standards (GBM/V4L2).

    b) The Pi graphics pipeline in the newer kernel used by LE10 has been rewritten around modern kernel standards (GBM/V4L2) so "assisted" decoding would need to be reimplemented from scratch in both kernel and ffmpeg. The original patches amount to 100,000 lines of code and authoring that (and then maintaining is downstream) is a large effort.

    c) Only a couple of distros (mainly LE and OSMC) have been daft enough to allow 100,000 LOC patches into their codebases so the audience that would benefit from a large reimplementation effort in 'B' is small.

    d) RPi4 and up support hardware HEVC decoding (although to be clear, forcing hardware upgrades on users has never been a goal). It does mean over time the issues reduces in size along with the RPi2/3 user population.

    e) Nobody is forcing users to update from LE9.2 which continues to have the feature.

  • I found today that on LE 9.2 / KODI 18 my TV Show scraper is no longer working. So unfortunately the e) above may not apply to everyone.

    I'm considering a reinstall.

    How can I tell if this issue affects me at all? I guess I should scan my video files? Is there an easy way to check this?

  • Ok. I can find affected mkv files like this:

    find . -name "*mkv" -print0 | xargs -0 -n 1 -t -J % ffprobe % -show_entries stream=codec_name -select_streams v:0 -of compact=p=0:nk=1 -v 0 > ~/ffprobe-result.txt 2>&1 &

    Works on BSD / Mac (xargs is non standard ...)

    Maybe dumb question: Is a hevc file not played at all or is this just limited in some way?

  • HEVC files will play but where 1080p was mostly possible under the legacy codebase 720p is probably the maximum now, and for encrypted streams like Netflix where DRM needs to be handled SD will likely be the limit.

  • I'm sorry to intrude, but is this specific to Raspberry or is it for all architectures?

    I'm into buying N100 based motherboard, and I'd like to have HW accelerated decoding of h264, h265 and AV1, which is supported by that iGPU. Should I postpone it?

  • I'm sorry to intrude, but is this specific to Raspberry or is it for all architectures?

    I'm into buying N100 based motherboard, and I'd like to have HW accelerated decoding of h264, h265 and AV1, which is supported by that iGPU. Should I postpone it?

    I believe this discussion is specific to the Pi2/3 HEVC implementation. That platform doesn't have VPU (video processing unit) support for hardware acceleration of HEVC/h.265 but instead uses a combination of CPU and GPU compute (not the same as dedicated VPU support) to allow HEVC content to be played on a platform that otherwise wouldn't be able to.

    The Pi 4 and Pi 5 both have hardware HEVC/h.265 VPU blocks to allow for hardware acceleration - which is supported in newer versions of LE.

    Other platforms like x86 which have 'GPU hardware decode' (which is more like VPU decode on ARM platforms) of HEVC are a different matter and depend on the driver support for that platform. I'd expect recent Intel CPUs to work fine once driver support for newer processors has made its way into the code base.

  • I am still using the "9.2.8" version on a RPI3B. It is amazing how it can decode 10bit 1080p x265 videos with ease. If i install the new version, even 720p videos suffer. This goes to show that when optimized, software can do amazing things, even on low end hardware. We don't really need all that power.

  • I am still using the "9.2.8" version on a RPI3B. It is amazing how it can decode 10bit 1080p x265 videos with ease. If i install the new version, even 720p videos suffer. This goes to show that when optimized, software can do amazing things, even on low end hardware. We don't really need all that power.

    To be fair - AIUI it's using GPU compute (i.e. offloading some computation to the GPU) to lighten the load on the CPU - so it's using more processing power than the CPU alone used for pure software decode can provide.