Bug 2071126

Summary:	RFE: enable support for V4L2 stateless decoders
Product:	[Fedora] Fedora	Reporter:	Peter Robinson <pbrobinson>
Component:	chromium	Assignee:	Than Ngo <than>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dominik, kwizart, leonard, nicolas, pwhalen, spotrh, than, tpopela, yaneti
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	chromium-110.0.5481.77-2	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-02-16 09:19:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	245418

Description Peter Robinson 2022-04-01 22:08:48 UTC

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.

Comment 1 Peter Robinson 2022-04-01 22:09:58 UTC

Note we already enable the Linux v4l2 interfaces as well as the appropriate drivers.

Comment 2 Peter Robinson 2022-04-04 08:08:43 UTC

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

Comment 3 Nicolas Dufresne 2022-04-04 14:03:45 UTC

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).

Comment 4 leigh scott 2022-09-02 11:12:37 UTC

(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?

Comment 5 Nicolas Chauvet (kwizart) 2022-09-02 11:28:50 UTC

> 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

Comment 6 Peter Robinson 2022-09-02 11:36:58 UTC

 
> 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.

Comment 7 Nicolas Dufresne 2022-09-07 16:53:53 UTC

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).

Comment 8 Nicolas Dufresne 2022-09-07 16:59:34 UTC

(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)

Comment 9 Than Ngo 2023-02-16 09:19:50 UTC

it should be fixed in chromium-110.0.5481.77-2.
  https://koji.fedoraproject.org/koji/taskinfo?taskID=97566238