Pi 400 and Debian Bullseye aarch64: Hardware Acceleration does not work

[Krawei]

Creating a bug report/issue

Required Information

• DietPi version | cat /boot/dietpi/.version
  G_DIETPI_VERSION_CORE=7
  G_DIETPI_VERSION_SUB=8
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'
  G_LIVE_PATCH_STATUS[0]='applied'
  G_LIVE_PATCH_STATUS[1]='applied'
  G_LIVE_PATCH_STATUS[2]='applied'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  bullseye 0

• Kernel version | uname -a
Linux Pi400 5.10.63-v8+ #1488 SMP PREEMPT Thu Nov 18 16:16:16 GMT 2021 aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  RPi 400 (aarch64)

• Power supply used | (EG: 5V 1A RAVpower)
  5V 3A

SDcard used | (EG: SanDisk ultra)
SanDisk Ultra

Additional Information (if applicable)

• Software title | Chromium/VC4
• Was the software title installed freshly or updated/migrated?
  freshly installed
• Can this issue be replicated on a fresh installation of DietPi?
  -yes

Steps to reproduce

1. Set up the Pi 400 and configure Chromium to use hardware acceleration as mentioned here: https://www.linuxuprising.com/2021/04/how-to-enable-hardware-acceleration-in.html
2. Install install libgles2-mesa libgles2-mesa-dev xorg-dev as mentioned here: https://forums.raspberrypi.com/viewtopic.php?t=319304
3. install vainfo
4. add h264ify to Chromium
5. Open a Youtubevideo of your choice in Chromium and check the used decoder by holding CTRL+SHIFT+i, clicking on the 3 dots => more tools => Media => click on the video stream under "players"
6. check vainfo

Expected behaviour

• Chromium should use the MojoVideoDecoder instead of the FFMPEGVideoDecoder
• Vainfo should show me the supported decoders
• ...

Actual behaviour

Chromium is using the FFMPEGVideoDecoder
vainfo is crashing for an unknown reason:
$ vainfo
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/aarch64-linux-gnu/dri/vc4_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Extra details

• Chromium was being forced to use Hardware acceleration by issueing
  $ chromium-browser --enable-features=VaapiVideoDecode. Under chrome:gpu it tells me:
  "Video decode: Hardware accelerated"

• Switching the Display drivers from full to fake kms via dietpi-config
  didn't help solving the issue.

• I noticed that dietpi-config is setting
  dtoverlay=vc4-kms-v3d
  instead of
  dtoverlay=vc4-kms-v3d-pi4
  . Could that be the issue?

[Joulinar]

not sure how up-to-date this post is https://forums.raspberrypi.com/viewtopic.php?t=275370
But it still contains following comment

Known issues

1. There is no hardware video acceleration in VLC or Chromium

[MichaIng]

vc4-kms-v3d on RPi 4/400 is internally translated into vc4-kms-v3d-pi4, so the latter does not need to be used in any case. Stated by the main RPi firmware engineer as I recognised vc4-kms-v3d being the default on Raspberry Pi OS and asked about that.

Note that the guide you followed is for Raspberry Pi OS 32-bit Buster while you use a 64-bit Bullseye image.

That the 64-bit Chromium does not support hardware acceleration on RPi may be outdated. I remember that time there was no chromium-browser package available for arm64, but now it is (and this is the one that is installed via dietpi-software): https://archive.raspberrypi.org/debian/pool/main/c/chromium-browser/?C=M;O=D

I guess it makes sense that we enable EGL by default, probably this is done by default with that build, but just to check whether it makes a difference:

sed -i '1s/$/ --use-gl=egl/' /etc/chromium.d/custom_flags
sed -i '1s/$/ --use-gl=egl/' /root/.chromium-browser.init

Run the browser as root user while testing, to rule out any permission issues. If accelerated video playback works as root, the required permissions/groups can be applied for the unprivileged login user.

Where do you get the info from that --enable-features=VaapiVideoDecode would be required or work at all on RPi? Note that VAAPI is an Intel GPU feature and unless there is some dirty wrapper hack this of course cannot work on an RPi with Broadcom VideoCore IV GPU. This renders of course also vainfo useless on RPi to get any valid info.
Ah I see it is mentioned in the forum thread you linked and indeed the error message indicates that it tries to invoke the VC4 video driver. Still not sure whether this is intended and any beneficial, at least on Bullseye. VAAPI has been explicitly disabled in the latest Kodi build for RPi OS Bullseye. It is enabled by default just to use that API if available and has proper fallback for other GPUs. But for an RPi-only build it doesn't make sense.

Could you try to remove the RPi camera kernel modules from the blacklist? With newer firmware, the legacy video decoding libraries are not used anymore, but V4L2 and libcamera instead. This was previously used only for the RPi camera module, hence we had those blacklisted when not having it enabled explicitly. Parts of those are now used (resp. can be used) for video/HEVC decoding. On Kodi this is the case at least, not sure whether the latest Chromium builds make use of it as well. Just to test it:

rm /etc/modprobe.d/dietpi-disable_rpi_camera.conf
modprobe bcm2835_codec bcm2835_v4l2

None of libgles2-mesa libgles2-mesa-dev xorg-dev is required. The first is a transitional dummy package. When enabling the KMS driver via dietpi-config, the actual libgles2 is installed automatically, and if I'm not mistaken as well when installing Chromium through dietpi-software as of package dependencies. The -dev packages are only required if you want to compile Chromium yourself, but not for running any executable. Generally, all required runtime libraries are pulled in automatically via package dependencies.

[Krawei]

I think I've found a possible solution.

After checking the Youtube hardware accelerated out-of-the-box experience with a freshly installed RPiOS aarch64 bullseye image, I was curious what that ootb-thing wasnt possible with dietpi so far.

While RPiOS plays any youtube video hardware accelerated in chromium without any quirks, just ootb, dietpi fails.

So I restarted step-by-step and was "victorious" at the end ;-).

What I've done:

• Revert to a fresh install

• installed via dietpi-software
  LXDE
  Chromium
  X.Org
  FFMPEG
  ALSA

• set via display options: vc4-kms-v3d as driver

• installed via apt
  chromium-codecs-ffmpeg-extra (this package wasn't bundled with the chromium-meta-package mentioned above)
  xserver-xorg-video-fbturbo
  gldriver-test
  inxi

• rm /etc/modprobe.d/dietpi-disable_rpi_camera.conf (as mentioned by MichaIng)

• reboot

=> done.

Now I see "VDAVideoDecoder" on any full-HD youtub video (with the CTRL+SHIFT+i debugging console).

What's funny: Chromium tells me via chrome://gpu "Video decode: Software accelerated". Maybe a bug in the interface?

So please feel free to verify my case and solution :).

In my opinion, the chromium-codecs-ffmpeg-extra, FFMPEG and maybe the fbturbo-driver package should be installed/bundled with the "chromium-meta-package"

Second the RPI-camera modules should be loaded by default.

Have a nice evening and stay healthy!

K.

[Joulinar]

There is one huge difference I guess. You used RPi OS Buster while we use RPi OS Bullseye to build DietPi. On Bullseye a different version if Kodi is used. It's Kodi18 on Buster vs Kodi19 on Bullseye.

[Krawei]

Sorry, I made a mistake. It was indeed a RPiOS bullseye image, not buster. Sorry!

[MichaIng]

On Bullseye a different version if Kodi is used. It's Kodi18 on Buster vs Kodi19 on Bullseye.

It's about Chromium.

@Krawei
Thanks for investigating and providing your solution. The chromium-codecs-ffmpeg-extra was missing, which is a special RPi only package, used only by the Raspberry Pi APT repository Chromium build, but does not exist on Debian (and wouldn't be used anyway). I didn't know about that, even that this exists since Stretch at least. So we'll add this to be installed by default with Chromium on RPi, which simply makes sense. That it depends on libraspberrypi0 indicates that it makes use of the RPi GPU features explicitly, like the regular ffmpeg package from that repository does. That all looks pretty fine 🙂.

The combination of vc4-kms-v3d and xserver-xorg-video-fbturbo doesn't make any sense. You enable the KMS driver but force X11 to keep using the legacy framebuffer driver (fbturbo aims to be a bit faster on ARM than regular fbdev, but otherwise it's the same). This should reduce your 2D/desktop performance (but doesn't have an impact on video playback most likely). So I suggest to simply apt purge xserver-xorg-video-fbturbo. With KMS enabled, X11 will by default use the included KMS/modesetting DDX driver, which should give best desktop/2D performance. If KMS is disabled, X11 will fallback to the separately installed fbdev DDX, which as said is nearly the same as fbturbo but does not force X11 to use it but is used as fallback then, which should be preferred.

Second the RPI-camera modules should be loaded by default.

Not the module (hardware) itself, or all related kernel modules, but the codec module at least. I need to ask Dom to verify which ones are used for video decoding and which ones by the actual RPi camera hardware only.

[MichaIng]

Issue solved with: f11e29e
I recognised that chromium-codecs-ffmpeg and chromium-codecs-ffmpeg-extra are two alternative package dependencies for the RPi kodi package, with chromium-codecs-ffmpeg being the default, which only supports patent-free format decoding. chromium-codecs-ffmpeg-extra adds support for all free and non-free formats.

Changelog: dcaa15c