[Pi 4] Lots of frame drops when playing high bitrate VC-1

1st Official Post

    I noticed that playing VC-1 endoced files leads to alot of dropped frames. In the first two minutes of the Blu Ray rip of The Boure Identity it says 86 dropped frames in the ctrl+shift+o overlay.

    The problem seems to be that the PI 4 does not have hardware acceleration for VC-1, unlike the Pi 3, and that the CPU is not quite powerfull enough to decode it via software. What make me belive that is

    • There are alot of dropped frames when playing h.264 when hw-decoding is deactivated, but no dropped frames, when it's enabled
    • The utilisation of one CPU core is always 90-100%
    • Framedrops appear mainly when the bitrate of the video is high (fast movement in bluray rips. Ctrl+Shift+O shows 25 to over 30 mBit/s video bitrate). Bitrates of up to 20-25 mBit/s seem to work fine.

    I tried all kinds of different setting like "automatically changing the screen refresh rate" on and off and "audio pass through" on and off, but nothing affects the dropped frames. I'll try overclocking the Pi in the next couple of days and see if that helps. Are there any other thinks I can try to imporve the situation?

    That does not seem to be it. "sync playback to display" was already off and the video file wasn't interlaced to begin with.

    I also already overclocked the pi to 1750MHz and it seems to help a bit with the issue

    I've also had this problem, I have set up two Raspberry Pi 3's for my kids and they have no problems playing VC-1, yet my RPi-4 drops alot of frames, I know its ment to be powerful enough to play VC-1 without the codec but I would prefer to spend a few quid and know it is just going to work

    Update: Just updated to Libreelc 10 with Kodi Matrix and now the frame drops are gone, but the VC1 Blu Ray rips still don't play smoothly. The movie runs too slow for half a second and then too fast for another half a second. It's just slightly, but still easily noticable

    Sounds like syncing refresh rate to display could help. Search for such an option at Settings -> System -> Video (expert mode), or at the playback menu (press OK while playing something, and select the gear wheel). I'm using a different RPi / LE version, so I just guess the location.

    Just had another look at it. At the end of the day the Pi 4 still does not have enough power to software decode smoothly. When it plays a low bitrate scene is runs smoothly and the CPU usage is a 30-40% in that example. In high bitrate scenes the CPU usage is at max and I get that too-slow-then-too-fast-playback again.

    I'ss try out if enabling syncing refresh rate to display helps

    Overclocking is the only thing that may help.

    VC-1 is poorly optimised in ffmpeg (about 40% of time is spent in C code loop filter functions).

    We have had a low-priority piece of work for our codec guy to write some Neon code for this which should resolve this, but the move to v4l2 and drm has kept the codec guy too busy to get to this.

    I have got the boss to okay another guy to work on this - so hopefully there will be progress soon.

    Quote from popcornmix

    I have got the boss to okay another guy to work on this - so hopefully there will be progress soon.

    Hello there,

    I bought recently an RPi-4 and ran into exactly the same issue about VC-1. I'm glad to know that a fix is on schedule for future releases.

    Thank you popcornmix an all LibreElec and Kodi developers for so much and so good work.

    The problem is that VC-1 software decoding in ffmpeg is single-threaded, it has always had a reputation as CPU intensive for this reason.

    However maybe the optimizations mentioned by popcormix will help

    Edited once, last by trent (January 18, 2022 at 4:45 PM).

    Work has just started on optimising VC-1. If anyone wants to provide a sample file (e.g. 1 minute section cut from a currently problematic file), then that will be checked when determining when performance is good enough.

    Ideally a harder section from a BluRay (e.g. where bitrate peaks, or we lose audio sync fastest).

    I am also impacted by micro-stuttering on high-bitrate VC-1 video files on a RPi 4 so I am happy to hear that there is a potential solution.

    popcornmix, is there any way to help out? I am not very knowledgeable in the low-level ffmpeg ARM assembly work that seems to be needed, but I could help test builds. Is there a merge request or something that we can follow to see how this work is progressing?

    Thanks again for all the hard work by the devs here.

    Looks like the last commit on that Github branch was from the end of March 2022. I'm curious if this fix was completed / merged into some version of libreelec at this point? I'm seeing these VC1 playback issues running libreelec v10.0.2 (RPi4.arm).