Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2071126 - RFE: enable support for V4L2 stateless decoders
Summary: RFE: enable support for V4L2 stateless decoders
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: chromium
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2022-04-01 22:08 UTC by Peter Robinson
Modified: 2023-02-16 09:19 UTC (History)
9 users (show)

Fixed In Version: chromium-110.0.5481.77-2
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-02-16 09:19:50 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.