chromium: hardware video acceleration with VA-API

Preycon · 2020-05-19 22:40:24

Still experiencing issues on Vega (Ryzen 2500u) on 60fps videos on Youtube...

liewkj · 2020-05-23 01:05:59

Preycon wrote:

Still experiencing issues on Vega (Ryzen 2500u) on 60fps videos on Youtube...

That was quite unbelievable.

I tried a 1:57 VR 360 60FPS VP9 video from YouTube. It played full-screen at 1280x720@60 with 0 frame dropped.
https://www.youtube.com/watch?v=-xNN-bJQ4vI

This was on the aging Core i3-4010U laptop with Intel HD 4400 (HSW GT2) using the VP9 hybrid driver. The CPU utilization might have been high as the fan spinning up faster than normal 10s into the video, but playback was absolutely perfect.

Did you get any error logs from the terminal console if you run chromium-vaapi from there?

dimischiavone · 2020-05-23 12:18:34

Preycon wrote:

Still experiencing issues on Vega (Ryzen 2500u) on 60fps videos on Youtube...

I am experiencing the same issues on Vega too (Ryzen 3700u pro).

Yaro · 2020-05-23 21:32:29

Never mind, I got it working. I'm still having stuttering issues on Youtube, though.

Last edited by Yaro (2020-05-23 21:36:36)

mrlamud · 2020-06-10 03:44:52

Yaro wrote:

Never mind, I got it working. I'm still having stuttering issues on Youtube, though.

I'd read a lot of people has problem with Ryzen APU ,however here I'm.
I just jumped from intel to Ryzen 3 3200G last Saturday.

The first time I visited youtube with this APU make me nervous because I got the same problem.

The mesa-git solves this youtube problem for me. It might - sometimes- cause some little problems but the maintainer is quick taking good care of it and also frequent update.

Either suggest mesa-git in AUR or from maintainer's repo (https://wiki.archlinux.org/index.php/Un … s#mesa-git)

Preycon · 2020-06-12 20:14:35

Can confirm that mesa-git from AUR fixes the problem, thank you!

sadboi777 · 2020-06-13 20:45:43

Anyone having problems with chromium-vaapi after the latest kernel update and mesa update? Mine stopped working and shows up like this: https://imgur.com/a/Qxyu59u even on the linux-lts kernel. I'm using the version from the archlinuxcn repo on GNOME X11.

Last edited by sadboi777 (2020-06-13 20:46:08)

iMeee · 2020-06-14 08:53:39

sadboi777 wrote:

Anyone having problems with chromium-vaapi after the latest kernel update and mesa update? Mine stopped working and shows up like this: https://imgur.com/a/Qxyu59u even on the linux-lts kernel. I'm using the version from the archlinuxcn repo on GNOME X11.

Exactly the same problem here, both and X11 and Wayland. It only seems related to mesa.

I had the following parameters in .config/chromium-flags.conf :

--enable-gpu-rasterization
--enable-native-gpu-memory-buffers
--enable-zero-copy
--disable-gpu-driver-bug-workarounds

Disabling those flags seems to solve the problem.

The problem had been reported already : https://gitlab.freedesktop.org/mesa/mesa/-/issues/3119

mrlamud · 2020-06-14 10:50:58

Preycon wrote:

Can confirm that mesa-git from AUR fixes the problem, thank you!

It seems the latest mesa 20.1.1-1 from official repo also solves the problem, too.

If you and anyone who use Ryzen with Vega APU still find that video streaming is not quite correct against hardware video acceleration is working, run this command to check if gstreamer-vaapi supports libva-mesa-driver.

 $ gst-inspect-1.0 vaapi

If the output yeild 0 feature then you have to set

GST_VAAPI_ALL_DRIVERS=1

as environment variable.

More information as per wiki https://wiki.archlinux.org/index.php/GS … _whitelist .

Last edited by mrlamud (2020-06-14 23:20:49)

sadboi777 · 2020-06-14 11:21:12

iMeee wrote:

sadboi777 wrote:
Anyone having problems with chromium-vaapi after the latest kernel update and mesa update? Mine stopped working and shows up like this: https://imgur.com/a/Qxyu59u even on the linux-lts kernel. I'm using the version from the archlinuxcn repo on GNOME X11.
Exactly the same problem here, both and X11 and Wayland. It only seems related to mesa.
I had the following parameters in .config/chromium-flags.conf :
--enable-gpu-rasterization
--enable-native-gpu-memory-buffers
--enable-zero-copy
--disable-gpu-driver-bug-workarounds
Disabling those flags seems to solve the problem.
The problem had been reported already : https://gitlab.freedesktop.org/mesa/mesa/-/issues/3119

I figured it out myself and downgraded the mesa package. I don't wanna add this to ignorepkg list so I hope this gets resolved in the next mesa update.
Shouldn't we report the bug on the Arch tracker too?

Last edited by sadboi777 (2020-06-14 11:22:36)

OdinEidolon · 2020-06-14 18:34:45

sadboi777 wrote:

iMeee wrote:
sadboi777 wrote:
Anyone having problems with chromium-vaapi after the latest kernel update and mesa update? Mine stopped working and shows up like this: https://imgur.com/a/Qxyu59u even on the linux-lts kernel. I'm using the version from the archlinuxcn repo on GNOME X11.
Exactly the same problem here, both and X11 and Wayland. It only seems related to mesa.
I had the following parameters in .config/chromium-flags.conf :
--enable-gpu-rasterization
--enable-native-gpu-memory-buffers
--enable-zero-copy
--disable-gpu-driver-bug-workarounds
Disabling those flags seems to solve the problem.
The problem had been reported already : https://gitlab.freedesktop.org/mesa/mesa/-/issues/3119
I figured it out myself and downgraded the mesa package. I don't wanna add this to ignorepkg list so I hope this gets resolved in the next mesa update.
Shouldn't we report the bug on the Arch tracker too?

Same issue here, and same "fix". Let's hope it gets fixed soon.

viggy96 · 2020-06-14 19:40:24

Is there any chance that Arch will build Chromium with VAAPI again for the official repo? It still doesn't affect the average user since hardware acceleration is disabled by default on Linux.

sadboi777 · 2020-06-14 21:41:24

viggy96 wrote:

Is there any chance that Arch will build Chromium with VAAPI again for the official repo? It still doesn't affect the average user since hardware acceleration is disabled by default on Linux.

No idea but they should, if Fedora and OpenSuse can, then so can Arch. Why was it taken off in the first place?

Last edited by sadboi777 (2020-06-14 21:41:50)

viggy96 · 2020-06-15 02:50:20

I'm not sure, but Arch should seriously do this, considering that Fedora and Ubuntu are shipping Chromium with VAAPI support.

viggy96 · 2020-06-18 14:25:31

Is there anyone on the Arch team that can chime in on this? Why was VAAPI disabled in the first place? Can we re-enable VAAPI support in the build again? This would benefit pretty much all users, and hurt no one, since hardware acceleration is not the default.

V1del · 2020-06-18 14:34:04

Read the first few pages of the thread instead of needlessly bumping here. It lead to actual issues for actual users. E.g. https://bbs.archlinux.org/viewtopic.php … 7#p1837037

viggy96 · 2020-06-18 15:04:58

I didn't see anything in this thread that suggested that users who didn't enable hardware decoding using flags experienced any issues. It appeared to me that all users who experienced issues were those who were using hardware acceleration. I don't see any examples of users who didn't enable hardware acceleration and still had issues.

liewkj · 2020-06-18 22:49:53

V1del wrote:

Read the first few pages of the thread instead of needlessly bumping here. It lead to actual issues for actual users. E.g. https://bbs.archlinux.org/viewtopic.php … 7#p1837037

I wish the package maintainer would stop living in the past and be more forward looking. All chromium issues including Wayland and VA-API have been resolved and patches are simple and easily maintainable. In my regard, chromium-vaapi is the best Linux browser for both X11 and Wayland DE. I prefer GNOME/Wayland on my laptop and rolling distro such as ArchLinux should demonstrate strong will in endorsing Wayland.

eschwartz · 2020-06-18 23:09:48

liewkj wrote:

I wish the package maintainer would stop living in the past and be more forward looking. All chromium issues including Wayland and VA-API have been resolved and patches are simple and easily maintainable. In my regard, chromium-vaapi is the best Linux browser for both X11 and Wayland DE. I prefer GNOME/Wayland on my laptop and rolling distro such as ArchLinux should demonstrate strong will in endorsing Wayland.

Why is it Arch's responsibility to "endorse Wayland"? Why isn't it Chromium's responsibility?

P.S. Firefox now has *official* Wayland support for VA-API hardware decoding (because Firefox is committed to officially supporting this on things other than special Google devices), and X11 support is in the pipes as well.

viggy96 · 2020-06-18 23:12:00

eschwartz wrote:

liewkj wrote:
I wish the package maintainer would stop living in the past and be more forward looking. All chromium issues including Wayland and VA-API have been resolved and patches are simple and easily maintainable. In my regard, chromium-vaapi is the best Linux browser for both X11 and Wayland DE. I prefer GNOME/Wayland on my laptop and rolling distro such as ArchLinux should demonstrate strong will in endorsing Wayland.
Why is it Arch's responsibility to "endorse Wayland"? Why isn't it Chromium's responsibility?
P.S. Firefox now has *official* Wayland support for VA-API hardware decoding (because Firefox is committed to officially supporting this on things other than special Google devices), and X11 support is in the pipes as well.

You're missing the main point, which is that Arch should reconsider its position on building Chromium with VAAPI support.

eschwartz · 2020-06-18 23:18:34

viggy96 wrote:

You're missing the main point, which is that Arch should reconsider its position on building Chromium with VAAPI support.

I'm not missing the point, I'm disputing it.

Again: It's the chromium team's job to reconsider its position, agree to support it officially, and make sure it works on current tech stacks or fix bugs that show up on Debian, Fedora, or Arch Linux systems. It's not Arch's job to downstream patch it, as proven by the fact that it broke when the maintainer tried it.

If you want to discuss philosophy, Arch Linux officially holds the position https://wiki.archlinux.org/index.php/Ar … Simplicity

Arch Linux defines simplicity as without unnecessary additions or modifications. It ships software as released by the original developers (upstream) with minimal distribution-specific (downstream) changes: patches not accepted by upstream are avoided, and Arch's downstream patches consist almost entirely of backported bug fixes that are obsoleted by the project's next release.

Building chromium with VA-API violates this philosophy.

...

As bit of friendly advice, unrelated to the discussion about modifying chromium...

If you really just want VA-API, vote with your feet. Ditch chromium, and use a browser that respects its users.

Last edited by eschwartz (2020-06-18 23:20:22)

viggy96 · 2020-06-18 23:23:34

Considering that Arch did once built with VAAPI before, I would say there is already precedent set for this.

liewkj · 2020-06-19 01:20:31

eschwartz wrote:

Again: It's the chromium team's job to reconsider its position, agree to support it officially, and make sure it works on current tech stacks or fix bugs that show up on Debian, Fedora, or Arch Linux systems. It's not Arch's job to downstream patch it, as proven by the fact that it broke when the maintainer tried it.

To certain extent, I think the chromium team already did, otherwise we won't see the display-less EGL code path that actually supported Wayland. Perhaps someone would dispute that it happened simply by accident because ChromeOS was based on Linux kernel without X, so EGL became the essential way to rid the dependencies on DE/WM. Fair enough, I cannot say that I disagree. All I want to say is the maintainer tried it at the wrong time. Being an ex-Ubuntu user as I looked into how VA-API was patched in the PPA, I would just forget it. Today, it is different, please open up your mind and enable VA-API simply by adding "use_vaapi=true".

eschwartz wrote:

If you want to discuss philosophy, Arch Linux officially holds the position https://wiki.archlinux.org/index.php/Ar … Simplicity
Building chromium with VA-API violates this philosophy.

In fact, I do not wish to argue along this line, but there are official Arch packages that already violate the philosophy. The end goal is to make Linux software ecosystem at parity with the Windows counterpart. I am glad that Firefox had finally picked up hardware video decode acceleration for Wayland and X11 support is in the pipe. But why ignore the fact that chromium already has it for both Wayland and X11 for a long time with just a simple additional build flag? It used to be that only build flag was required (which did not violate Arch Linux simplicity) before the recent regression that broke Intel VA-API on Wayland. Bug had been filed upstream and simple 2-liner patch was made available. Personally, I don't think taking this patch would violate Arch philosophy of simplicity but help to promote Wayland endorsement as Intel GPUs dominate the mobile space and VA-API is crucial in this space.

eschwartz · 2020-06-19 02:06:14

liewkj wrote:

eschwartz wrote:
Again: It's the chromium team's job to reconsider its position, agree to support it officially, and make sure it works on current tech stacks or fix bugs that show up on Debian, Fedora, or Arch Linux systems. It's not Arch's job to downstream patch it, as proven by the fact that it broke when the maintainer tried it.
To certain extent, I think the chromium team already did, otherwise we won't see the display-less EGL code path that actually supported Wayland. Perhaps someone would dispute that it happened simply by accident because ChromeOS was based on Linux kernel without X, so EGL became the essential way to rid the dependencies on DE/WM. Fair enough, I cannot say that I disagree. All I want to say is the maintainer tried it at the wrong time. Being an ex-Ubuntu user as I looked into how VA-API was patched in the PPA, I would just forget it. Today, it is different, please open up your mind and enable VA-API simply by adding "use_vaapi=true".

This is empirically untrue. At a minimum, you need to patch the source code to remove a check that says "Accelerated video decode is unavailable on Linux", plus several `#if defined(OS_CHROMEOS)` to allow Linux as well.

In fact, that's *exactly* the patch which was used for a short while in the Arch repositories.

liewkj wrote:

eschwartz wrote:
If you want to discuss philosophy, Arch Linux officially holds the position https://wiki.archlinux.org/index.php/Ar … Simplicity
Building chromium with VA-API violates this philosophy.
In fact, I do not wish to argue along this line, but there are official Arch packages that already violate the philosophy.

This is invalid logic. If something is axiomatically held to be bad, but is sometimes done anyway, it does not constitute a valid justification to do it more, or again.

Valid justification to do it more, or again, would be to plead a special exception, which must be done each time on a case-by-case basis, or to argue that the axiom itself is wrong and should be revised.

"But other packages do it" is never an excuse, and, personally, the only effect this argument has on me is to make me more convinced that "it" should not be done -- because if there was a good reason to do it, people would not resort to the "someone else broke the axiom first" defense.

liewkj wrote:

The end goal is to make Linux software ecosystem at parity with the Windows counterpart.

That may be your end goal, but I don't really see this as inherent to the Arch Linux ethos. In fact, I would argue that in some ways it's strictly against the Arch Linux ethos. Many parts of the Windows software ecosystem follow principles that are rejected by Linux distros as a rule, for example, Windows makes it easy to install self-contained software bundles and have multiple (outdated) versions of the same software installed, in the name of compatibility; meanwhile, Linux advertises one single version which is known to work on the distro, and intertwines it so deeply into the system that you cannot download and install an old or new version except with difficulty. (But there is always flatpak. In fact, flatpak would let one install a chromium-vaapi.)

"Parity" is not really a goal. Linux, and Arch Linux, is focused on balancing the concerns of itself, and being the best self that it can be within those guiding principles. Sometimes that means Arch Linux can do things Windows cannot, and sometimes that means Windows can do things Arch Linux cannot.

Sometimes it means Arch Linux can do the same things Windows can do, but in a different way. Perhaps "use Firefox" is a different way?

liewkj wrote:

I am glad that Firefox had finally picked up hardware video decode acceleration for Wayland and X11 support is in the pipe. But why ignore the fact that chromium already has it for both Wayland and X11 for a long time with just a simple additional build flag? It used to be that only build flag was required (which did not violate Arch Linux simplicity) before the recent regression that broke Intel VA-API on Wayland. Bug had been filed upstream and simple 2-liner patch was made available. Personally, I don't think taking this patch would violate Arch philosophy of simplicity

Again, it's not a simple build flag.

It's a simple build flag, plus a few simple ifdefs, plus disabling a special upstream message that it's explicitly disabled on Linux...

It's a matter of opinion whether it violated Arch Linux simplicity during the time it was enabled in the past. The maintainer made a judgment call that it was warranted, as is his right, and later made a judgment call that the experiment produced bad results, and reverted it. Personally, I would argue that it was always violating Arch Linux simplicity, the issues that arose were indicative of the troubles one gets by patching around upstream, and that my concern was vindicated.

Of course, all that too is just my opinion. Ultimately, it is up to foutrelis to decide whether it is worth it. And my opinion is not even a high priority anyway, because I'm not exactly a chromium user to begin with...

liewkj wrote:

but help to promote Wayland endorsement as Intel GPUs dominate the mobile space and VA-API is crucial in this space.

Arch Linux does not have a mission statement to endorse Wayland as Intel GPUs dominate the mobile space.

As for me personally? I dislike Wayland and believe it's a pointless technology. I believe it's at best a decade or two away from being a truly practical X.org replacement, and at worst Wayland is a technical preview.

I may or may not be right in my opinions on Wayland, but I am certainly not the right person to listen to your argument that Arch needs to do something because it will help promote Wayland...

(And also oh yeah, because I dislike Chromium too. )

viggy96 · 2020-06-19 02:22:04

Valid justification to do it more, or again, would be to plead a special exception, which must be done each time on a case-by-case basis, or to argue that the axiom itself is wrong and should be revised.

Isn't this exactly what we're trying to do here? We're trying to argue that at the very least, Chromium should be an exception, as the benefits vastly outweigh the breaking of some ideal that Arch Linux holds.

Arch Linux

#326 2020-05-19 22:40:24

Re: chromium: hardware video acceleration with VA-API

#327 2020-05-23 01:05:59

Re: chromium: hardware video acceleration with VA-API

#328 2020-05-23 12:18:34

Re: chromium: hardware video acceleration with VA-API

#329 2020-05-23 21:32:29

Re: chromium: hardware video acceleration with VA-API

#330 2020-06-10 03:44:52

Re: chromium: hardware video acceleration with VA-API

#331 2020-06-12 20:14:35

Re: chromium: hardware video acceleration with VA-API

#332 2020-06-13 20:45:43

Re: chromium: hardware video acceleration with VA-API

#333 2020-06-14 08:53:39

Re: chromium: hardware video acceleration with VA-API

#334 2020-06-14 10:50:58

Re: chromium: hardware video acceleration with VA-API

#335 2020-06-14 11:21:12

Re: chromium: hardware video acceleration with VA-API

#336 2020-06-14 18:34:45

Re: chromium: hardware video acceleration with VA-API

#337 2020-06-14 19:40:24

Re: chromium: hardware video acceleration with VA-API

#338 2020-06-14 21:41:24

Re: chromium: hardware video acceleration with VA-API

#339 2020-06-15 02:50:20

Re: chromium: hardware video acceleration with VA-API

#340 2020-06-18 14:25:31

Re: chromium: hardware video acceleration with VA-API

#341 2020-06-18 14:34:04

Re: chromium: hardware video acceleration with VA-API

#342 2020-06-18 15:04:58

Re: chromium: hardware video acceleration with VA-API

#343 2020-06-18 22:49:53

Re: chromium: hardware video acceleration with VA-API

#344 2020-06-18 23:09:48

Re: chromium: hardware video acceleration with VA-API

#345 2020-06-18 23:12:00

Re: chromium: hardware video acceleration with VA-API

#346 2020-06-18 23:18:34

Re: chromium: hardware video acceleration with VA-API

#347 2020-06-18 23:23:34

Re: chromium: hardware video acceleration with VA-API

#348 2020-06-19 01:20:31

Re: chromium: hardware video acceleration with VA-API

#349 2020-06-19 02:06:14

Re: chromium: hardware video acceleration with VA-API

#350 2020-06-19 02:22:04

Re: chromium: hardware video acceleration with VA-API

Board footer