Chromiun now supports upstream Linux V4L2 stateless decoders along side the ChromeOS specific APIs, as well as the stateful codecs. From the rpmfusion bug report: This is a feature request, I am willing to help with the actual work if with some pointers (as I don't know were to start). Chromium Freeworld package enables VAAPI HW decoding which is great of Intel/AMD platforms, but I'd like to have a HW accelerated browsers on Raspberry Pi, Rockchip RK3399 and more. Chromium have support for this, though it has to be compiled in. This is used on ChromeOS ARM Chromebook. There is in fact 2 type of CODECs, stateful and stateless. The stateful one will enable H264 on Raspberry Pi, but also enable SoC running Qualcomm Venus driver, Amlogic CODECs, etc. The stateless situation was a bit in flux until now, as Chromium was implementing few downstream kernel API and did not have support for the final uAPI yet. This situation is fixed now, so support for final uAPI for H.264, VP8 and VP9 is now available.
Note we already enable the Linux v4l2 interfaces as well as the appropriate drivers.
So in theory all that should be needed is the following addition to the spec but it fails and I don't understand the Chromium builds well enough: %ifarch aarch64 CHROMIUM_CORE_GN_DEFINES+=' target_cpu="arm64"' +CHROMIUM_CORE_GN_DEFINES+=' use_v4l2_codec=true' %endif
Got slightly more info today, there is a CL from Wens to op-out any downstream uAPI support in linux builds. https://chromium-review.googlesource.com/c/chromium/src/+/3380426/4 Though he said that there might be some issues related to some downstream GBM deps they have (to be confirmed).
(In reply to Peter Robinson from comment #2) > So in theory all that should be needed is the following addition to the spec > but it fails and I don't understand the Chromium builds well enough: > > %ifarch aarch64 > CHROMIUM_CORE_GN_DEFINES+=' target_cpu="arm64"' > +CHROMIUM_CORE_GN_DEFINES+=' use_v4l2_codec=true' > %endif The(In reply to Peter Robinson from comment #2) > So in theory all that should be needed is the following addition to the spec > but it fails and I don't understand the Chromium builds well enough: > > %ifarch aarch64 > CHROMIUM_CORE_GN_DEFINES+=' target_cpu="arm64"' > +CHROMIUM_CORE_GN_DEFINES+=' use_v4l2_codec=true' > %endif You need chromium-105, it's the first release that includes the required merge. https://chromium-review.googlesource.com/c/chromium/src/+/3380426/4 Than there is a choice to be made vappi or v4l2 as they don't coexist. https://pkgs.rpmfusion.org/cgit/free/chromium-freeworld.git/commit/?id=f243c20ce3687bb47c902c2d1d130fa6dd3f3085 Which is more useful, vaapi or v4l2 support?
> Which is more useful, vaapi or v4l2 support? I've raised the point to IRC #tegra liberachat about their vaapi-tegra-driver (1) over a v4l2 implementation 1: Current review is at https://bugzilla.redhat.com/show_bug.cgi?id=2023429
> Which is more useful, vaapi or v4l2 support? ATM on arm at least the v4l2 support is probably more useful as it's supported on a wider set of platforms (rockchip, nxp imx8, qcom, allwinner) which are likely to be used with chromium.
I'm not aware of any working VA-API driver for any of the ARM64 SoC, so for ARM64, V4L2 seems more useful. I believe we get both stateful and stateless decoders though, which means it will cover for both RK/NXP (stateless) and QCOM/Amlogic/RPi (stateful), Allwinner is not supported (at least not yet).
(indeed, newer Tegra would be a challenge, the older Tegra has a V4L2 stateless driver, but I believe it needs something not yet passed by chromium, an easy fix though)
it should be fixed in chromium-110.0.5481.77-2. https://koji.fedoraproject.org/koji/taskinfo?taskID=97566238