@tartanpion re: why it failed:
In one case I compiled with v4l2 without disabling vaapi, and in the other case I think I tried to compile chromium from archlinux (non-ALARM)
Some of my observations:
The V4L2 decoder usually crashes on twitch and youtube, and chromium immediately replaces it with FFmpegVideoDecoder.
On my OPi5+, when I run ozone-backend=x11 (which doesn’t use explicit-sync from the mentioned commit), then the video stutters every few seconds.
I personally avoid the crashes by using the Vulkan backend. Unfortunately vulkan-panfrost is not bug-free. Some websites have graphical glitches and V4L2 videos often end up with major glitches.
On my Opi5+ with “ozone-platform=wayland” and using enhanced-h264ify to limit to h264, the video stream smoothly. Currently on RK3588 the v4l2request only support h264 format. At times can stream youtube for 15 minutes or more but does crashes randomly.
Same experience launching Chromium with X11, video stutters.
That commit adds a fallback for explicit sync. It is no longer relevant today, since chromium nowadays does explicit sync using the drm-syncobj wayland protocol. On rk3588, this still crashes, albeit less often.
I compiled chromium with WaylandBufferManagerHost::SupportsAcquireFence() changed to always return false. Seems to work. It hasn’t crashed yet.
What puzzles me is that the commit message says that explicit sync is required for vulkan to work, but vulkan somehow still works?
I think vulkan requires X11 to work on chromium. I recently switched to wayland and if i activate vulkan, i lose all hw acceleration. Under X11 that wasn’t the case.
Hopefully this can be default chromium build on alarm repo too.
Edit: 2025-06-05
Manjaro-opi5plus-xfce-6.15.1-1 (labwc-wayland-session) chromium-137.0.7151.55-2 streaming 1080/60 videos with hardly any drop frames using “V4L2VideoDecoder”. Good.
So far chromium-137.0.7151.55-2 is stable on “–ozone-platform=wayland”.
That sounds great. This was only possible on x11. You got me interested now i will just remove the flatpak version and install this.
Is there any flag i should enter to get the v4l2 video decoder working?
By the way, the last update was on january. Arch Arm seems like they have given up on chromium and will no longer update it. Can we (manjaro arm) have a different repository for our own chromium then? Would that be possible?
Flatpak version was just updated to 137. I tried to open a youtube video (1080p 60hz) and although it is still watchable, it still drops a bunch of frames.
Ok so people can build chromium for their own manjaro arm setups and post their installation packages, that is fine but, if they can do it, arch arm itself should be able to do it. So why don’t they? I just checked and it is still version 131. I am fine with using the flatpak version for the moment but why is chromium being neglected like this? It is not Google Chrome, it is the open source chromium. It should be available.
Arch arm webpage and forum is struggling lately, all the more fire to the suspicion that arch arm is dying. If you haven’t received the confirmation e-mail by now (it was instant for me), you won’t receive it any time soon. I seriously think that, just maybe, Manjaro ARM should start considering a backup strategy in the case that arch arm gives up the ghost. Gentoo maybe? Or Alpine?
Thanks. Downloaded chromium_138. Hopefully alarm can use your chromium package build.
Edit: Chromium-138.0.7204.49-1 so far is stable with “–ozone-platform=wayland” and h vpu hardware acceleration works. Thanks.
2025-07-25
Hi @maxjrh,
With the last few linux-6.16.6, 6.15.7, 6.15.8 kernel after boot up there is around 50% chances where chromium_138 will not have vpu hw acceleration and need a reboot for chromium_v138 to regain vpu hw acceleration (sometimes more than one reboot).
I’ll have to test it out a bit. Right now, I am running chromium without the vpu flags for two reasons:
It crashes on MPEG-DASH websites like twitch and youtube. chromium then replaces the decoder with the software decoder. Sometimes this crashes the whole gpu process and chrome://gpu shows software acceleration only.
Videos that use heavy compression don’t work properly. It will have a lot of sub-block artifacts that don’t update properly. This is a problem on e.g. nebula.tv and some videos in my own jellyfin.
I hope that the google team improves the v4l2 decoder and that it becomes usable in a future version. On my OrangePi5+ it is not yet usable. It is usable on my Thinkpad x13s, which has a v4l2 stateful decoder (but bullet point 1 still applies)
So far on my Opi5plus, once it boot up and chromium_v138 have vpu hardware acceleration, I have no issue with streaming the Youtube videos that I play and it stays that way until next reboot (logout it ok, chromium vpu hw acceleration remain intact)
The only issue is around 50% of the time on boot up chromium no vpu hw acceleration.
Edit: 2025-07-28 Update on Chromium_v138 vpu hardware acceleration @maxjrh,
To compare with linux-6.15.8-1 on chromium vpu hardware acceleration availability and general functionality.
With 6.15.0-1-aarch64-rk3588-collabora-git, manjaro-opi5plus-xfce chromium_v138 have vpu hardware acceleration 6 out of 6 boot/reboot where as with linux-6.15.8-1 usually on 50% of the time. Based on memory linux-6.15.3-1 chromium vpu hw acceleration availability is much better on boot up than linux-6.15.8-1 (not sure what have changed).
Kernel 6.15.0-1-aarch64-rk3588-collabora-git have few functions not available as compared to Manjaro kernel linux-6.15.8-1. On kernel 6.15.0-1-aarch64-rk3588-collabora-git wifi is available for my RTL-8852BE module and hevc decode is also not available. There might be other functions not available compared to Manjaro kernel linux-6.15.8-1 which have not tested/tried yet.
You can give this kernel a try to see whether it improved on your chromium vpu hw acceleration availability/crashes?
On my Opi5+, I always see consistent behavior after every reboot, no 50/50 random chance. Maybe it is because I have UEFI on SPI?
I tried out the kernel you linked. that one has support for rkvdec2 (rk3588 has two vpu blocks on chip).
It works pretty well:
no blocky artifacts
works on youtube
still doesn’t work on twitch though
Unfortunately, on that kernel usb-tethering doesn’t work, so I’ll have to compile my own kernel. (My Wi-Fi chip is old and unreliable due to overheating)
I have u-boot loader from Joshua Riek Ubuntu on the SPI. Which kernel are you on? Manjaro linux-6.16.0-1 or linux-6.15.8-1 where is are able to have chromium vpu hw acceleration on every boot up?
Use to be able to with linux-6.15.3-1 with chromium. And with collabora-git kernel. But now with linux-6.16.0-1 NO chromium_v138 vpu hw acceleration at all. But vpu hw acceleration is available on mpv-full-git and clapper media player (both using v4l2-request too, if not mistaken).
Do you us any /etc/environment settings or configuration? What chromium flags you use?
On both 6.16 and 6.15.8 I get the same behavior as usual. It “works” except for the completely unacceptable bugs described above.
It does work flawlessly in mpv-full-git and clapper.
My chromium-flags.conf
Are you booting up Manjaro-opi5plus with UEFI-EDK2? Which Manjaro-opi5plus you use?
Videos that use heavy compression don’t work properly. It will have a lot of sub-block artifacts that don’t update properly. This is a problem on e.g. nebula.tv and some videos in my own jellyfin.
KDE-Neon (Ubuntu) chromium-mpp stream http://nebula.tv with NO vpu hw accelertion. No visual artifacts while streaming nebula.tv but after I ended the video chromium-mpp have visual artifacts on other webpage.