DietPi OS for Quartz64

[stormwyrm]

Using mpv made the difference, not Trixie.

I tried MPV on Bookworm too. It struggled with 720p with just as many dropped frames as MPlayer and VLC.

I tried mplayer and VLC because those are the players I use on regular amd64 Linux and they're still working well enough there. I'd not thought to look into newer systems as they were unnecessary on PC hardware.

[diederik]

VLC is (normally) an excellent player. I don't use it much, but I know many people do (and prefer it over others). The situation on amd64 might be different, but I guess you normally use more powerful hardware and therefor don't notice it's (now) using the CPU for playing? It could also be that it's actually using HW-accell on amd64 as that uses different APIs.

Hmm, it could be that I only tested it on Trixie (on my PineTab2 which has the same SoC), but I tried various Desktop Environments and while mpv worked fine*, VLC and gnome player couldn't play x264 videos I tried it with.

*) Max 1080p and full CPU usage, but it worked

[MichaIng]

Using mpv made the difference, not Trixie.
It seems MPlayer has been brought back from the dead some time ago, but it's still got a few years of catching up to do. It's a mystery to me why you would want to use it (instead of mpv).
VLC (or gnome's video player) for some reason can't handle 720p or 'even' 1080p. I have a vague recollection that VLC hasn't moved to ffmpeg 5 yet (let alone 6 as used in Trixie).

And I'm quite sure that hardware acceleration is NOT working (unless you patched several things for that).
You'll likely see CPU usage on all cores of 80-100% as it does all things on the CPU, which means it's indeed not using HW-accel.

You mean also with mpv CPU acceleration is high? If it works better, then obviously it does something better, making some use of a supported/accelerated API, not sure. I see now that all those players are compiled against FFmpeg libraries. Also VLC, which means it uses FFmpeg v6 on Trixie: https://packages.debian.org/trixie/vlc-p...deo-output

Could you test/compare playback just with ffplay?

---

VLC is (normally) an excellent player. I don't use it much, but I know many people do (and prefer it over others). The situation on amd64 might be different, but I guess you normally use more powerful hardware and therefor don't notice it's (now) using the CPU for playing? It could also be that it's actually using HW-accell on amd64 as that uses different APIs.

Hmm, it could be that I only tested it on Trixie (on my PineTab2 which has the same SoC), but I tried various Desktop Environments and while mpv worked fine*, VLC and gnome player couldn't play x264 videos I tried it with.

*) Max 1080p and full CPU usage, but it worked

Probably the reason is that VLC displays playback through X while mpv (as CLI player) uses DRM? Does it make a difference when playing a video outside of any X/desktop session with vlc (CLI command) from bare shell session?

Both pull FFmpeg codec libraries, so I guess for video decoding, all those tools (vlc, mpv, ffplay), should perform similar. So I guess the difference comes from displaying it. But not sure, also I lack some knowledge about the different stages of video playback and at which stages the GPU can kick in, and which library/driver influences this.

---

I checked a little further about which codecs are actually expected to be supported by this SoC/GPU/VPU. Not sure whether it is current: https://wiki.pine64.org/wiki/Mainline_Hardware_Decoding

So H.264 up to 1080p should be supported.

Did someone check other threads here or at LibreELEC regarding this, how others got it working (if at all)?

[diederik]

You mean also with mpv CPU acceleration is high?

No. There is no CPU acceleration, only software decoding on the CPU. Acceleration happens via hardware.
If CPU utilization is 80-100%, then there is no hardware acceleration.
With HW-accel the CPU usage drops to ~20%

If it works better, then obviously it does something better, making some use of a supported/accelerated API, not sure. I see now that all those players are compiled against FFmpeg libraries. Also VLC, which means it uses FFmpeg v6 on Trixie: https://packages.debian.org/trixie/vlc-p...deo-output

I don't use VLC myself, so I don't keep track of its development. Thinking back I should've known that couldn't be it.
I just took a quick look and noticed that the 3.0.x series is from 2018, so that's probably what I actually vaguely recalled.

Could you test/compare playback just with ffplay?

I don't need to as I already know that the current ffmpeg does not support the HW-accel API(s) that are needed.

Probably the reason is that VLC displays playback through X while mpv (as CLI player) uses DRM?

Ah, that would explain why VLC performs so poorly on Quartz64 devices. With the panfrost driver, you REALLY want/need wayland.

Not sure whether it is current: https://wiki.pine64.org/wiki/Mainline_Hardware_Decoding

So H.264 up to 1080p should be supported.

I don't know how up-to-date the page is. A `git blame` would've made it much easier to check when it was last updated, but (afaik) that's not available.
I (also) don't know how the video pipeline works exactly and if/when/how Hantro would be used.

I do know that there's current development to get HW-accel working and that you need to patch multiple components to get it to work at all.
But my testing indicated it's not ready for general usage yet.

[MichaIng]

I meant "CPU usage", of course, not "CPU acceleration". But you answered that already.

Which needed API is not supported by FFmpeg?

You can easily install a desktop with Wayland on Debian. Not via dietpi-software, but the APT packages are all there, and some desktops even use Wayland by default. Have a look here: https://wiki.debian.org/Wayland
But I am not sure whether this really makes a difference. Wayland is probably less overhead, but I bet best still is direct DRM from console, if HW acceleration is missing.

You can see the last edit of the linked wiki page via "View history", just like on Wikipedia. The last change was recently, but about RK3588, and there is no guarantee that all info is up-to-date only because there has been a commit recently. The only thing we can take from it is that the chip generally supports accelerated video decoding for relevant codes, and that H.264 acceleration "should" be there, kernel and software-wise (which does not say that the actually used builds or players do).

Could you share some links about the HW acceleration development for RK3566/Mali G52? I would be open to apply some kernel patches, when they are not too intrusive (hence require not too much maintenance). But for the software/player side, patches/custom builds is outside of scope/time I can afford for this.

[sickos]

The only way I've found to get video hardware acceleration with rk3566 in a video player using mainline kernel is with flathub clapper player. This is due because gstreamer can call the Hantro driver of rockchip. You get a low 20% of cpu usage with 1080p video. It doesńt work with 4K because of Hantro.

[kup4ooo]

Hi! I have Pine64 SOQUARTZ V1.1, that should run on BTT Manta M8P - for controll 3d printer.
When I upload fresh image on sdcard and boot - all looks fine. After SSH login it begins updates,
then it writes that it should update the kernel and need to reboot, but when go to shutdown nothing happens.
Just overheat and nothing. Even with hard reboot wont boot.

[ifreislich]

The problem is the firmware-soquartz package which breaks u-boot. You can either pin the package by creating /etc/apt/preferences.d/firmware-soquartz with the following contents before you boot the image for the first time:

Code:

Package: firmware-soquartz
Pin: version 6.9.4-*
Pin-Priority: 999

Or build u-boot by following the build instructions at Quartz64 Building U-Boot - PINE64 but

Code:

git checkout v2024.04

before configuring and building u-boot.

Use this command to write the working u-boot to your media:

Code:

sudo dd if=u-boot-rockchip.bin of=/dev/your_sd seek=64 bs=512