[RPi5] H.265 Stuttering

    Hi all,

    I've been troubleshooting persistent stuttering when playing 4K HDR H.265 content on my Raspberry Pi 5 running LibreELEC 12.2.1 and wanted to share my findings in case it helps others or someone knows a fix.

    My setup:

    • Raspberry Pi 5 running LibreELEC 12.2.1 (RPi5.aarch64)
    • Synology DS418play NAS serving files over NFS
    • Optoma UHZ35 4K beamer via Denon AVR-X2500H receiver
    • All connections via Cat6 gigabit ethernet and 2.0 HDMI cables

    The problem: 4K HDR H.265 files stutter for 4-5 seconds every 1-2 minutes. Multiple different files all exhibit the same behaviour.

    What I've already ruled out:

    • Network speed is fine (confirmed gigabit via ethtool)
    • SD card speed is fine (87 MB/s confirmed via dd)
    • CPU usage during playback is only ~30%
    • Cache settings are optimized (500MB buffer, readfactor 20 in advancedsettings.xml)
    • NAS drive hibernation is disabled
    • Refresh rate switching is working correctly (3840x2160 @ 23.976Hz)
    • LibreELEC is fully up to date

    What I found in the logs: The kodi.log shows the file is hevc (Main 10), yuv420p10le, bt2020, smpte2084 and the following errors repeat constantly during playback:


    Code
    kernel: rpi-hevc-dec 1000800000.codec: Missing DPB ent 0, timestamp=0
kernel: rpi-hevc-dec 1000800000.codec: Missing DPB ent for col
ffmpeg[0x0]: [hevc] Could not find ref with POC 240
ffmpeg[0x3a48370]: [hevc] frame_post_process: Decode fail
ffmpeg[0x0]: [hevc] First slice in a frame missing.

    The decoder being used is CDVDVideoCodecDRMPRIME via /dev/dri/card1.

    Disabling hardware acceleration results in unwatchable performance (as expected for 4K software decode), so that's not a viable workaround.

    My question: Is this a known issue with the rpi-hevc-dec driver on Pi 5 for Main 10 content? Is there a nightly build or kernel parameter that addresses this? Any workaround short of transcoding all my files to 8-bit?

    Thanks in advance!

    The hardware decoder is reporting missing information in the media; which normally indicates a media problem and not a decoder problem. FWIW, i'm running my own RPi5 development image (LE13 not LE12) with a broadly similar setup and I don't see the same errors with a wide selection of test, broadcast, and self-ripped 10-bit HEVC media.

    Feel free to test https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz - make a backup of /storage/.kodi first as Kodi does not support downgrades. There are also some binary add-ons missing in the repo that image uses right now, but that will resolve itself over the next 24h or so as they are built and published.

    Thank you so much for the help!

    I started off with popcorn's idea to rule out any network related issues, and tadaaa, it played the same file from a USB disk straight away without any problems. This means the Raspberry functions perfectly and I have to look further within my network.

    Thanks!

    K22/LE13 supersedes all the advancedsettings.xml cache tweaking (that most users misunderstand and thus get wrong) with some sensible defaults and also reworks the SMB client. Perhaps update to a current nightly and see if that resolves issues.

    hmm..

    I did some testing of my own with the Salyut7 UHD. The beginning sequence with the cosmonauts floating around the station is almost unwatchable due to stuttering on the rpi5 even when played from local disc (nvme in this case). The same sequence when played on my old NUC 11 plays without stuttering even over the network. But of course the nuc doesn't do audio, so that's
    that.

    I then had an idea. I took the original 70GB file instead of the 12gb recoded (with handbrake). And lo and behold, no stuttering. So it seems the decoder on the rpi5 has a problem with the recoded stuff, maybe not enough I frames, too long Gops? Is this something that can be adjusted in the decoder?

    I'll try the same with some other videos where I saw stuttering (I.e. James Bond No time to die, the beginning car chase sequence)

    Other than that, I'll have to see if I have to do something about the recoding (using of course Quicksync, Sw only is way too slow). Any hints welcome.

    If you are using the wrong presets when ripping or converting media, change the presets to ones that work on your hardware. If you are stealing the media off the internet and expect all the random encodings that have been used to work on all hardware; a) you will be dissapointed, and b) we don't care about that problem.