I'm on meetings with Zoom here which are overpowering my cpu. I'll update once the 6.2x kernels come out. But meantime, I did some hunting with vcgencmd (well hidden in /opt/vc/bin) and measured clocks. The vcgencmd Man page says: So I ran the same command on slarm64-15.0 & the 64bit Debian bullseye while running the same h264 video in vlc. Here's the outputs I had the command line saved and copied & pasted it in both instances, so it's unlikely to be different. I do have slarm64 mildly overclocked, CPU @2GHz, GPU@600MHz. To my less educated eye, it seems there's a lot more GPU running in debian than there is in slarm64. The h264 & isp blocks are running, which you would expect running a h264 video.

Any thoughts why so little GPU runs in slarm64? Will 6 kernel 6.2.x do anything to improve things?

all this is configurable and has nothing to do with the system.

Thanks for the reply.

The page you linked is rpi-0 & rpi-1 specific and seems not even to cover the Pi 2, and doesn't have anything on the Pi 3/4. Nevertheless, there are some useful utilities in the rpi-userland package and I'll see what I can do with them. I can also compare debian's config, which does seem to get better video results. Any link that's Pi-4 specific and works would be great, because I'm heading out of hardware config (my area) and into software. Anything on the rpi-4 on raspberrypi.org seems out of date and/or broken links.

One thing I noticed is that the dtoverlay command errors out with From what I've read, that's buried in /sys, and some guy on stackoverflow even cobbled up a module for it. But the device-tree doesn't show under /sys with kernel-5.16.7. If I knew what it was looking for and could mount it, there's an option allowing me to specify another directory.

Well, I discovered a few things. I found this one section of video that wouldn't render on slarm64. VLC had 6-8 threads open, and because of the way the load was unevenly spread, the video was stopping as htop showed the load was looking for >100% on two cores, and they could only give 100% each. Total CPU load on top showed at about 280%, with two cores more than maxed out.

I then booted Debian Bullseye (the rpiOS 64bit), loaded the same section of the same video in VLC on Debian Bullseye. Bullseye rendered it well. The total cpu load was about 80% between the 4 cores. That's a pretty striking difference.

As for 'everything being configurable,' the option returns the settings on the two command options, int & string. This paste is a comparison of the debian and slarm64 configs, and there's more differences there than I seem to be able to adjust with config.txt. I have caught debian out patching the wifi firmware, so it's certainly not beyond them to patch anything.

It is difficult to get any real data. Stuff on config.txt covers rpi 0-4, cm4 & 400 and the hardware differs greatly. I can only find the odd explanation for some random fact online. One such is the difference between the vc4-kms-v3d.dtbo & vc4-fkms-v3d.dtbo. There are two conflicting explanations in the RazPi documentation, and forum. The f stands for "fake kms" and gives a degree of leniency to the software. My box switches off the GPU and graphics are all kernel done by the kernel & Mesa. Debian makes the GPU work, with superior results and much lower cpu load.

is the kernel version the same?

Debian*(not updated) has 5.15.16 and I have 5.16.7. I also unearthed that loads the vc4-kms-v3d driver, so if you want the vc4-fkms-v3d driver, you have to disable that. I gather the 6.2.x kernel is on the long finger. Conflicting explanations don't help, but it seems vc4-kms-v3d seems to use firmware to set video modes, whereas vc4-fkms-v3d lets the kernel set them. I still haven't found why the gpu is unused, and it's not the firmware, because debian turns it on witrh the same firmware.

well, these are different kernels, 5.15.y is stable and it includes and implements something that is not in 6.x.y

I've chased up the differences as much as I can, and stopped. Here's what I found. Slarm64's Software versions are a a few minor numbers up on RPi OS, although Debian test more and patch things.

Xorg.0.log seems similar in both systems. I compared Xorg.0.log files. They load the same modules get the same reactions in the logs. The RazPi firmware & hardware remained the same. I compared file sizes. The only patch I suspected was an (earlier) version of the vc4-kms-v3d overlay being 1K bigger, so I tried that in slarm64. It may have made a small improvement.

To eliminate vlc, I tried your other mp4 players. Firefox offers to play .mp4s using QAV. It gave me a small black window, I heard the soundtrack, but saw nothing. MPV played the test video section just about, but it was spreading cpu load better over 4 cores whereas vlc seemed to concentrate the load on three. Load was up to 325% at times, to judge by the htop graphical output.

Next thing is the kernel. I can't compare module size because theirs are compressed; I can't compare configs, because Debian don't supply one. Suspiciously, all their module trees are numbers like '5.15.16+' which nearly implies patching, but what I've found is a long way off Red Hat's revisions.

Lastly, I'll mention my test video is 1080p, and I'm using one hdmi-1.0 monitor. I'd have no chance on 4k, requiring four times the bandwidth, let alone 2 of them! That's what the Pi is supposed to drive.

One last try. I got your latest current on an sdcard, and tried that. It just about works with mpv at 350% cpu with tell-tale signs of overloading, e.g. legs moving jerkily. Shrinking the size of displayed video did next to nothing. Slackware Arm seems little better. Kernel 6.0.9 seems to have no acceleration enabled.

The latest kernel is 6.1.1, so 6.2 could be three months away. Debian beckons.....

EDIT: I'm not a Debian fan, but on my test video, Debian is showing 60-70% on top...

Everyone chooses what is more comfortable for him.
you can try kernel 5.15.34 and use

Slackware is much more comfortable for me, and slarm64 of the Aarch64 offerings.

But Debian doesa the business, and slarm64 doesn't, unfortunately. I have debian 64bit on an sdcard but not on disk. I'm mounting the Slackware /home to access the videos. But slarm64 isn't driving the GPU, and that needs rethinking.

This might help you finger it. I tried three videos

• An mkv
• An mp4
• An avi

On Slarm64, the same few bits of the gpu regardless. All were pretty cpu heavy.
On Debian, different cpu configurations were applied. The h264 block was on for the h264 video. It remained off on Slarm64.

Their Xorg modules are smaller than yours. Maybe it's a kernel thing?

I wrote above that you need to change to the kernel 5.15.y and change the driver to fkms

OK, I will.

I couldn't change to 5.15.34, but your site did have 5.15.80-generic, so I "Upgraded" to that from 5.16.7-bcm2711. That gave me no sound. It evidently didn't recognise the audio. It also crashes on shutdown, but I know what will fix that . My considered opinion is that that kernel isn't very generic. The 6.0.9-bcm2711 kernel had sound. My only output device option on 5.15.80-generic is 'dummy output.'
I tried the video regardless of sound on 5.15.80, and it's worse. So I said to myself "Never mind, I'll stick in Debian," but the sdcard chose that moment to remind me how unreliable sdcards are. I don't see any point in trying 5.15.19-generic. So I'm stuck restoring my backup of 5.16.7-bcm2711 because I never had the package, without disturbing my recent installs.

Debian isn't all plain sailing either, btw. The key difference is that when debian sets up the gpu for the job on hand, but slarm64 is doing all software. So when debian plays a h264 video, it wakes up the h264 block in the gpu, but slarm uses the cpu. That's why debian performs better.

EDIT: The firmware is in the bcm2711 kernels, so that explains loads