I have beat my head against the wall on the Raspberry pi forums for hours on this, but I am shocked to find nothing that makes sense.
I KNOW that in Stretch the Raspberry Pi 3B+ is COMPLETELY capable of playing 1080p mp4 with ZERO issues on VLC, because I used it as my media machine for YEARS. No desktop slowdown, no UI issues - just plays the video like I was opening it on a modern multi-core machine. The microSD card that was still in there when I pulled it out still DOES function that way, although it’s obviously now an unupdatable security nightmare…
But it seems that every new Raspbian OS update after that… bullseye, trixie… all play video like they’re broken lemons. Playing through VLC is still PASSABLE with massive frame drops and awful UI lag, but playing video in a browser just displays solid pink colors, despite hardware acceleration being enabled.
What changed? Is it just the Wayland switch? Is it just impossible to use these things to their full potential anymore? I hate to throw out perfectly good old hardware that clearly CAN perform my use case, because the OS broke compatibility with it.
Can anybody explain what happened, or if it’s fixable?
I didn’t dive too deep into this when I encountered it, and instead just avoided decoding on the device itself, so my apologies if I am incorrect here.
I’m fairly certain you are being affected by the removal of OpenMax. Since OpenMAX hardware decoding was not actively in development, it didn’t make the transition to 64-bit and was removed in bullseye, replaced by v4l2. Unfortunately it seems like v4l2 wasn’t a 1:1 replacement and people (like me) just gave up. You can try using that post to see if your h264_v4l2m2m package can be installed, and that might fix it… but if it doesn’t I’m not sure what you can do.
I tend to think you’re on the right track with hardware decoding issue. The hardware accelerated video in-browser is the giveaway for me - it’s not FAILING, it’s just giving incorrect output. chrome://gpu SAYS hardware acceleration is enabled, but all videos just turn into a pink screen.
At any rate, I’ll look at this suggestion you posted. Thanks!
No luck. I guess I just have to come to terms with the fact that the idea that new Raspbian versions are the definitive, up to date solution for old models is just a lie. The hardware decoding for the 3B+ is just broken. Just surprised how little I see about it.
What encoding are the files? Given that it sounds like this is an old set up and maybe old files, some raspberry Pis and I’m pretty sure the 3b was one as I had one, did have support for hardware decoding mpeg 2 (maybe others, I don’t remember), BUT this required purchasing a license for it. I never did, so idk what form the license came in. If it was a file on your SD and you don’t have it on your new installs, that’s my bet. Either that or newer software is more bloated or otherwise performs worse making the experience overall worse. Sometimes on old hardware, older software is the better choice (ignoring security of course).
Nice thought, but it’s exactly the same files. 1080p mp4s. I’ve tried them on both installations. Simply, they play without even the tiniest hint of a hitch on Stretch, and on Bullseye it’s like there’s no hardware acceleration at all.
Edit: For what it’s worth, it’s not only the 1080p mp4s. 720p mp4s are much the same. Smooth as butter on Stretch, barely chugging out on Bullseye.
This may seem pedantic, but mp4 is a container that holds the video and audio streams. The actual video stream can be encoded im various formats (mpeg 2, h264, h265, etc). If you open vlc and look at the codec menu, find the video stream and report back the encoding type it may provide some insight. It could be that there’s a performance regression with a particular decoder or maybe they changed decoding library or any number or things. Sorry it’s a bit vague, but what I’m getting at is if we know the actual video encoding of the file it may help to track down the decoding performance issue.
If it does turn out to be mpeg2, it could be that something changed about how the video decoding drivers (kernel module) are loaded. Like maybe they stopped including them by default or are no longer being used for some reason.
If it’s not mpeg 2, then could look in to decoder specific changes between distro versions or hardware support related changes (like maybe a kernel module needs an extra config passed to it to get better performance on 3b), or even decoder library config may be possible to tweak. Sometimes performance optimizations make things worse and the new default configs work better on newer hardware but worse for you.
In any case, I think knowing the specific video encodings would be helpful. I also just remembered that I had some performance issues on some files due to audio formats if I was having the Pi software decode vs connected to an external AV receiver that could decode the bit streamed audio data.
Not pedantic at all! You’re right, of course.
The exact encoding is:
H264 - MPEG-4 AVC (part 10) (avc1)
I ran into something similar when in haste I went from Raspbian Stretch to plain Bookworm and discovered the Debian version of Kodi didn’t have all the userspace drivers to drive the hardware decoding. In the end I worked around it by running Kodi from a container with stretch in it until the official Raspbian Bookworm got released. Maybe you could build a stretch based container for your VLC setup?
