[Orange Pi 3 LTS] MPEG2 HW decoding results in frame processing timed out & page faults

    With MPEG2 HW decoding enabled on LE 12 (nightly, 08/29) certain MPEG2 videos result in the following errors from the kernel:

    Sep 04 07:02:37 LibreELEC kernel: sun50i-iommu 30f0000.iommu: Page fault for 0x0000000000007000 (master 1, dir rd)

    Sep 04 07:02:39 LibreELEC kernel: cedrus 1c0e000.video-codec: frame processing timed out!

    And in Kodi the experience is a spinning disc while the player is trying to start the video. If you use CEC remote it will result in a Kodi lock-up (but shell is still responsive), if you try to stop and restart the video it will also result in a Kodi lock-up. I tried doing a video clip for uploading with:

    ffmpeg -ss 00:00:00 -to 00:01:00 -i mpeg2-h6-decode-full.mkv -c copy -map 0 mpeg2-h6-decode.mkv

    And it result in these warnings in ffmpeg and a working video in Kodi (original video still does not work and is 2GB):

    [matroska @ 0x556df9223f40] Non-monotonous DTS in output stream 0:0; previous: 2018, current: 1951; changing to 2018. This may result in incorrect timestamps in the output file.

    [matroska @ 0x556df9223f40] Non-monotonous DTS in output stream 0:0; previous: 2018, current: 1985; changing to 2018. This may result in incorrect timestamps in the output file.

    Here is the sample, copied with dd partially, that results in this issue:

    mpeg2-h6-decode.mkv

    Thanks chewitt for the tip. :)

    Edited 3 times, last by frakkin64: Merged a post created by frakkin64 into this post. (September 4, 2023 at 1:07 PM).

    Quote from jernej

    But that doesn't solve it. Video stream is corrupted. Not sure if it's possible to find a way to normally decode frames. Still, Kodi should deal with corrupted frames better...

    I don't know much about V4L2, but it sounds like the primary focus (in this scenario) is HW decoding video frames and presenting that to the display framebuffer, and I presume something else is synchronizing audio/video and that it should check for corrupted frames. I assume for SW decoding (which works fine) it is just presenting raw video frames to V4L2 (since it is already decoded).

    I would say that this problem isn't unique to Allwinner, as I mentioned Amlogic had the similar struggles with corrupted videos. RPi4 is, of course, using FFmpeg SW decoding and that works fine on all platforms (FFmpeg seems pretty forgiving and does fixups during playback).

    I can wait and see how LE 12 progresses, but I want to say this was an issue with LE 11 because I stopped using this device, went back to the Amlogic device on CE (but it's starting to get a little flakey with the SD card slot) for a while. Maybe I'll give LE11 a test on an SD card, and report back. As it stands now, the workaround me is to just drop MPEG2 in the driver capabilities, and it takes about 50% CPU on all cores for a full 1080i video which is not a big deal.

    Quote from frakkin64

    I presume something else is synchronizing audio/video and that it should check for corrupted frames.

    Kodi is responsible for sync and yeah, I think code isn't optimal.


    Quote from frakkin64

    I assume for SW decoding (which works fine) it is just presenting raw video frames to V4L2 (since it is already decoded).

    V4L2 is just for decoding and possibly deinterlacing. Rendering is done using either DRM planes (default) or GPU, but you're right in principle.

    Quote from frakkin64

    As it stands now, the workaround me is to just drop MPEG2 in the driver capabilities, and it takes about 50% CPU on all cores for a full 1080i video which is not a big deal.

    Maybe an option can be added to disable HW decoding for specific codecs on the fly? I think that would be best.