10.0 Beta 3: Garbled H264 video playback on Raspberry Pi 4

    I've been using LibreElec / Kodi on a Raspberry Pi 4 for quite a while now, and of course I am looking forward to the upcoming 10.0 release. Today I tried 10.0 Beta 3, using a fresh SD card as recommended in the release notes. Everything worked nicely, the user interface is rendered smoothly and system information shows that the CPU load is minimal, looks even better than with 9.2.x.

    However there's a problem with playback of H264 video. I've also tried mpeg4, that seems to work fine. But any H264 encoded movie, or stream (I tried Vimeo), comes out totally garbled. In some films some i-frames seem to render okay, but most of the time the picture is so garbled that it's almost inconceivable. Here's an example picture, most of the time it looks even worse:

    The Raspberry Pi is attached via HDMI to a projector with 1080p resolution. Needless to say that the same movies and streams play back nicely using the 9.2.x release.

    I've attached a debug log and the kernel output, let me know if any other details are needed:

    kodi.log  dmesg.txt

    Can you confirm if playing a file locally still has the problem? (e.g. copy to sdcard or attached USB stick)

    If it does can you provide a sample file? (e.g. cut a 1 minute chunk that shows the problem and upload to a site like dropbox/google drive)

    Sure. I copied "Big Buck Bunny" to the SD card. That movie has less artifacts than most other H264 encoded movies I tried. It doesn't make any difference though if it's played from SD card or from a network share. The artifacts appear at the very same frames, it's all very reproducible. The first artefacts appear about 10 seconds into the movie. The scene with the bird starting at 0:16 is rendered cleanly again, the next scene switch at 0:23 starts with artifacts. I've taken the attached picture at around 0:26:

    I've uploaded the first minute of the file here, of course after verifying that the cut version shows the artefacts as well:

    big_buck_bunny_1080p_h264_start.mov

    Edited 3 times, last by svenfoo (May 25, 2021 at 3:19 PM).

    Quote

    Your link is wrong, but if you are saying it fails with standard big_buck_bunny_1080p_h264.mov then that is a file that is tested regularly and plays fine.

    I am sorry, I don't know how I managed to mess up the link. The link should work again now, I edited the post. But yes, it's the standard file.

    Quote

    Can you try adding "over_voltage=2" to config.txt on boot partition and test again?

    Tried that, and it doesn't seem to make a difference. I've verified that /flash/config.txt has the entry. Can I somehow verify that it is being picked up by the boot-loader? Couldn't find CPU voltage under /sys.

    To rule out problems with the power supply, I replaced the 3A USB C power supply with the USB C charger from my notebook. Doesn't make any difference either.

    Edited once, last by svenfoo (May 25, 2021 at 5:10 PM).

    Thanks for pointing me to vcgencmd.

    Code
    # vcgencmd get_config over_voltage
over_voltage=2

    So that seems to have been picked up correctly. And unfortunately it doesn't solve the problem.

    Quote from svenfoo

    To rule out problems with the power supply, I replaced the 3A USB C power supply with the USB C charger from my notebook. Doesn't make any difference either.

    That may not prove anything. Most notebooks' USB-C power supplies only provide limited power at 5V. They use the smart capability of USB-C to change voltage and may then switch up to much higher voltage and current. I don't think that the Pi does this smart voltage changing, and so it might still be constrained by limited power availability unless the 5V capability of your other supply at least matches that of the Pi power supply. Certainly your screens shots suggest a hardware or power related issue.

    Quote from popcornmix

    This feels like a hardware issue. Did HW h.264 decode on that board work with LE9/Kodi 18?

    Just swapped the SD card to go back to LE 9.2.6 and played the same movie. The info display says the decoder in use is ff-h264-mmal (HW). That means it's using the hardware decoder, doesn't it?

    Quote from S80_UK

    That may not prove anything. Most notebooks' USB-C power supplies only provide limited power at 5V. They use the smart capability of USB-C to change voltage and may then switch up to much higher voltage and current. I don't think that the Pi does this smart voltage changing, and so it might still be constrained by limited power availability unless the 5V capability of your other supply at least matches that of the Pi power supply. Certainly your screens shots suggest a hardware or power related issue.

    You are right. According to the specs the Lenovo USB-C power supply only provides 2A at 5V. My USB-C 130W powerbank specifies 3A/5V so I tried that today, but the problem doesn't go away. I am perfectly willing to accept that it's an issue with the power supply. However the fact that the same hardware on the same power supply doesn't show any such issues running LE 9.2.x makes me wonder if it can possibly be a hardware problem.

    Quote

    When the video is corrupt, and you bring up OSD, is that clean, or have corruption?

    The OSD is clean. I can see that the video below is corrupted, but the overlay is rendered cleanly.

    Can you give me any advice on how to proceed? Could the decoding artifacts be caused by under-voltage? I'd go ahead and order a replacement power supply then, but is there any chance that this will actually fix the problems that I described?

    Your sample file plays correctly for me on a Pi4.

    So, either problem is with your Pi4 hardware, power supply or something wrong on sdcard (incorrect settings/corruption).

    Usually an issue with power supply generates an "Under-voltage detected!" message in dmesg, so I'd be surprised if that fixed it.

    You could try a clean install to a different sdcard to rule the sdcard contents out.

    Ideally, if you could find another Pi4 to test your sdcard/power supply/TV etc with then we could be sure if it's the Pi4 or not.

    One last thing. Try adding "gpu_freq=250" and "arm_freq=600" to config.txt. That will make the Pi4 much slower, but I'd be interested if corruption is still present.

    After trying pretty much everything else (replacing the power supply for example), I eventually replaced the Raspberry Pi, and voila, everything works nicely. It looks a lot like this was indeed a hardware issue. I still don't know what exactly is broken since the hardware worked flawlessly with version 9.x. But I'm a happy user of version 10.0.1 with the new Raspberry Pi 4B board now. Thanks for your patience and support.