Enable v4l2 hardware accelerated video decode for ARM devices

[Adam Smith]

Chromium browser is capable of decoding video via v4l2 codecs. ChromeOS uses this on arm devices to achieve good performance.

Patches to enable this in Linux can be found here https://github.com/Igalia/chromium/commit/58cca7607828bbadc4e154dde36e9c96469ba2d0 and here https://github.com/Igalia/chromium/commit/c607620917eee5ff646b2daf304f6f133fb24ada

[RussianNeuroMancer (russianneuromancer)]

Fedora developers enabled video decoding in their builds. Is anyone from Canonical can comments on this?

[RussianNeuroMancer (russianneuromancer)]

https://src.fedoraproject.org/rpms/chromium/c/278c62709d1dba5883c3b69047706837bb402bd7?branch=master

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michel-Ekimia (michel.ekimia)]

You meant VAAPI, not v4l2 , isn't it ?

[Daniel van Vugt (vanvugt)]

V4L2 doesn't have anything to do with video decoding that I know of, but maybe ARM is different...

Yes I think that should read "VAAPI", not "V4L2".

[Daniel van Vugt (vanvugt)]

Seems both statements are true :)

The above patches relate to parts of the Chromium source named V4L2. But for the most efficient desktop video decoding you need to use VAAPI (https://bugs.chromium.org/p/chromium/issues/detail?id=463440).

I'm not sure those two are related, or that the former can be used to help desktop like the latter does. So the Bug Description is very confused at the moment. To resolve that confusion please log a bug with Chromium upstream requesting whatever you think is missing and we can then rely on upstream's answer:

https://bugs.chromium.org/p/chromium/issues/list

[Daniel van Vugt (vanvugt)]

More information about VP9 and other decoding in V4L2:
https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/extended-controls.html

I think that relates to Digital TV tuners only, and am not sure it applies to machines that don't have any digital TV hardware attached.

[Adam Smith (adamsmith)]

Vaapi is not the only mechanism that can be used for hardware decode. V4l2 is an alternative, the one that will be used on the raspberry pi with the open source vc4 driver (see blog posts https://anholt.github.io/twivc4/2018/02/12/twiv/ ). I believe there is some communication between chromium and the pi makers about implementing this, but I am doubtful this will make it upstream.

[RussianNeuroMancer (russianneuromancer)]

Daniel, should we fill separate bugreport regarding VA-API? Or, perhaps, if you understand situation better, you can fill it?

Merge request: https://chromium-review.googlesource.com/c/chromium/src/+/532294

Upstream answers:
https://bugs.chromium.org/p/chromium/issues/detail?id=463440#c68
https://bugs.chromium.org/p/chromium/issues/detail?id=463440#c77

"This is not a burden we want to take on, as we don't have plans to release the feature in the product, or otherwise need it for development."

So, with not implemented video decoding in Firefox, here we are - patched Chromium packages in disributions seems like laptop/tablet users last resort, as upstream "don't have plans to release the feature in the product". I guess that why Chromium packages in Fedora is patched now.

[Adam Smith (adamsmith)]

There is already a bug for vaapi - bug 1424201

[Daniel van Vugt (vanvugt)]

Thanks for the information all.

We would need to find out if video decoding hardware exists behind V4L2 in the desktop case, or if that's just for Pi/ARM hardware. I strongly suspect it's the latter.

Also, since bug 1424201 is older and more generalized, I think this bug should be marked as a duplicate of that. It's always a bad idea to describe a solution in a bug rather than just the problem. Because most of the time that solution turns out to be the wrong one for the problem.

P.S. I am not working on video decoding any more. Only triaging bugs.

[Paul Menzel (paulmenzel)]

I believe, although bug #1424201 is assigned to *chromium-browser*, it is too general, as it also mentions and links to Mozilla bug reports. Therefore, that one should be closed or treated as a “tracking report” – if Launchpad allows that, and individual reports should be created for each browser.

[Daniel van Vugt (vanvugt)]

One of the benefits of Launchpad over other bug trackers is that we can spread a single bug over multiple components. And those different components have different Status values within a single bug. Bug 1424201 does that.

/Sometimes/ separate bugs do get created for different components, but in this particular case I think it is illustrative for all the information about multiple browsers to be visible on a single page.

[Adam Smith (adamsmith)]

My concern is that v4l2 will be forgotten about on the other bug report. Va-api won't work on the pi.

[Daniel van Vugt (vanvugt)]

That's a good point. If a single component needs multiple different fixes like separate ones for desktop and Pi then separate bugs are really required.

This one is now reopened. Please reword the bug title here to make it more obvious this one is about Pi/ARM only.

[Daniel van Vugt (vanvugt)]

Please also ensure there is an upstream bug report for this problem in:

  https://bugs.chromium.org/p/chromium/issues/list

and then tell us the bug ID.

[Adam Smith (adamsmith)]

I asked on the pi forum if they could help with the upstream bug report https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=233552 . I like the pi, but the people that make it are obnoxious. They are not going to help.

I posted some more patches from endless os in that thread.

[RussianNeuroMancer (russianneuromancer)]

It's seems like there is a progress on getting Qualcomm Venus decoder works on Snapdragon-based laptops so this feature could be useful for these laptops too: https://github.com/bm16ton/yoga-c630-linux-kernel