chromium: hardware video acceleration with VA-API

eschwartz · 2020-06-19 02:47:34

viggy96 wrote:

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.

Yes, it is true that the two of you have been arguing in favor of a special exception. That's a valid argument to make, and can be discussed.

My counter-argument was "it broke before, there's no guarantee it won't keep breaking". Also my understanding was that this broke by default, if chromium was compiled with vaapi then it was on and users either benefited automatically or had a completely unusable chromium, automatically.

liewkj · 2020-06-19 02:51:24

eschwartz wrote:

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.

You had failed to listen. I cordially invite you to look into chromium-vaapi AUR. There is only 1 additional patch file named vdpau-support.patch. Ungoogled-chromium AUR has 1 more patch named fix-intel-vaapi-wayland.patch. None of those deal with `#if defined(OS_CHROMEOS)` as you had assumed. What you just pointed out was the old, ugly patch from Ubuntu PPA and that was the reason that I urged the maintainer to be open-minded and re-consider current situation. Things had changed. Prior to the Intel VAAPI Wayland regression, it was indeed only the build flag `use_vaapi=true`. I spoke out of facts rather than out of assumption. The message "Accelerated video decode is unavailable on Linux" remains on chromium-vaapi build as always ever since Maximbaz dumped the ugly patch.

eschwartz wrote:

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

In my opinion, hardware accelerated video decoding is an important department to be at parity.

eschwartz wrote:

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

Cool I knew how it was going to be for Wayland non-believer. Though not a fonder of Chromium you are, Firefox is betting the future on Wayland as it seemed.

viggy96 · 2020-06-19 03:11:17

eschwartz wrote:

Yes, it is true that the two of you have been arguing in favor of a special exception. That's a valid argument to make, and can be discussed.
My counter-argument was "it broke before, there's no guarantee it won't keep breaking". Also my understanding was that this broke by default, if chromium was compiled with vaapi then it was on and users either benefited automatically or had a completely unusable chromium, automatically.

My understanding is that by default, hardware acceleration is still disabled by default, even when compiled with VAAPI support. The user has to specifically enable hardware acceleration using the appropriate flags in the "chrome://flags" page. I looked through this thread to see if any users had reported issues even when they hadn't enabled hardware acceleration, and I didn't see any such reports. So it is my understanding that the by default, users would remain unaffected. But for those who wish to use (or at least try to use) hardware accelerated video decoding, the feature will actually function, due to the binary having that functionality exposed by virtue of being compiled with the appropriate VAAPI feature.

seth · 2020-06-19 05:47:39

liewkj wrote:

I knew how it was going to be for Wayland non-believer.

Don't derail the thread, https://bbs.archlinux.org/viewtopic.php?id=130309 - see the last paragraph.

What makes you believe this to be a wayland/X11 issue? VAAPI is designed to be DRM agnostic and DRI to circumvent the X11 server.
There could of course be a massive bug in DRI or the DDX, but that would hit across the board and I'd rather expect problems in libva, drm or the kernel module.
Reg. the display server, I'd much rather suspect relation to the usage of a specific compositor.

Do people who experience issues w/ HW accelerated chromium also experience those issues w/ HW accelerated mpv/ffmpeg?

If it's "Because chrome-os!!!" - the benign explanation here is that this affects a limted and tested HW stack and the malign/paranoid explanation is that google is biased.

viggy96 wrote:

My understanding is that by default, hardware acceleration is still disabled

idk because it's unavailable, but the key is "#disable-accelerated-video-decode" what sounds like it's autodetected or enabled and you've to overrule to disable it.
Depending on how hard it would be to reverse that, such default reversal would certainly be a mitigating step to imo allow for a "risky" build, since arch users can be expected to actively seek features, but nobody should be thrown buggy defaults at.

liewkj · 2020-06-19 08:33:06

seth wrote:

What makes you believe this to be a wayland/X11 issue?

I did not. The message I was bringing out was Chromium with VA-API works for both Wayland and X11 *right now*. All the past issues were resolved and it only requires additional build flag `use_vaapi=true` to make it happen. This was the case for several stable releases until the recent Intel Wayland regression, and even that had been root caused with simple 2-liner patch made available.

seth wrote:

Do people who experience issues w/ HW accelerated chromium also experience those issues w/ HW accelerated mpv/ffmpeg?

Yes and No, but it is pointless to go there. The goal is to be able to obtain hardware video decode acceleration right from the browsers without any tricks behind the scene.

seth wrote:

If it's "Because chrome-os!!!" - the benign explanation here is that this affects a limted and tested HW stack and the malign/paranoid explanation is that google is biased.

Biased on which ground? Limited and tested HW stacks? You must be kidding. VA-API is now supported by both AMD (through MESA VA drivers) and Intel. This is at least 90% of x86 market and almost every AMD/Intel CPU shipped in the last 5 years has media accelerator block. That was probably the reason why Firefox eventually picked up hardware video decode acceleration through VA-API while it had been available on Windows for years through DXVA.

seth wrote:

idk because it's unavailable, but the key is "#disable-accelerated-video-decode" what sounds like it's autodetected or enabled and you've to overrule to disable it.
Depending on how hard it would be to reverse that, such default reversal would certainly be a mitigating step to imo allow for a "risky" build, since arch users can be expected to actively seek features, but nobody should be thrown buggy defaults at.

No it is not. While the old, ugly patch in the past from Ubuntu PPA might have patched through the roof to enable it by default, this is not the case now. Please do not make assumption if you do not use Chromium. There is no buggy defaults with VA-API build when the GPU blacklist is in-placed. Firefox Wayland VA-API employs the same strategy with MOZ_ENABLE_WAYLAND=1.

Last edited by liewkj (2020-06-19 08:38:30)

seth · 2020-06-19 10:01:57

Well,

liewkj wrote:

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.

kinda left the impression that one should ignore issues w/ X11 because it works with wayland and and wayland is the future and the following posts for some reason revolved around wayland as well.
So we can end *that* debate right here.

it is pointless to go there

The point was to narrow whether existing issues extend beyond the browser implementation (ie. "where is the bug really"), not to look out for "tricks behind the scene" (like deferring the playback to another process)

Biased on which ground?

paranoid explanation

I'll try to rephrase this, but keep in mind that this is moot since you're not actually arguing that "X11 is broken, but it must be working on wayland because it's enabled on chromeos".
---
The benign reason: "We think this is generally buggy, but can say that it works on certified chromebooks, thus it's enabled on this system"
The conspiracy theory on that explanation is that google seeks world domination through chromeos or something like this. Not kidding, no.
---

I do use chromium and would certainly like to have HW accelerated video back (had no problem w/ the patched libva-vdpau)
But the (currently deactivated) key is in fact labeled "#disable-accelerated-video-decode" and "when the GPU blacklist is in-place" actually confirms the assumption that it "sounds like it's autodetected".
A false assumption would however be that blacklists are inherently bullet-proof. Hence, and reg. the state of the arguement and the positions presented in this thread, the suggestion to default to an unconditional opt-in to definitively avoid broken default behavior and side-step that argument.

I suggest to take a step back, take a deep breath, assume that you're not in some sort of combat here and present your case why chromium should be build w/ vaapi enabled as straight as possible (what changed compared to last year, what will be required, why it's safe or what are the remaining risks etc.) instead of opening side-topics.

Eg. you didn't address what was probably and I understood as Eli's most important position:

eschwartz wrote:

Also my understanding was that this broke by default, if chromium was compiled with vaapi then it was on and users either benefited automatically or had a completely unusable chromium, automatically.

and instead focused on some irrelevant "Wayland non-believer" side-show. That's not productive.

liewkj · 2020-06-19 11:20:27

seth wrote:

I suggest to take a step back, take a deep breath, assume that you're not in some sort of combat here and present your case why chromium should be build w/ vaapi enabled as straight as possible (what changed compared to last year, what will be required, why it's safe or what are the remaining risks etc.) instead of opening side-topics.
Eg. you didn't address what was probably and I understood as Eli's most important position:
eschwartz wrote:
Also my understanding was that this broke by default, if chromium was compiled with vaapi then it was on and users either benefited automatically or had a completely unusable chromium, automatically.
and instead focused on some irrelevant "Wayland non-believer" side-show. That's not productive.

I am pretty sure that eschwartz's context got it all wrong, and Google clearly documented how to enable unsupported VA-API for Linux.

To run Chromium using VaAPI two arguments are necessary:
--ignore-gpu-blacklist
--use-gl=desktop or --use-gl=egl

I believe I had repeated enough that today *ONLY* `use-vaapi=true` build flag is required without patching a single upstream source file. Please do not take my words, look at the AUR yourselves. The additional patches are simply nice to have for:

NVIDIA vdpau wrapper
Intel Kabylake VP9 playback anomoly
Wayland/EGL regression

Without patching a single upstream source file, VA-API works for unaffected Intel GPUs on X11 sessions, AMD GPUs (r600, radeonsi) on both X11 and Wayland sessions, though I strongly recommend taking patches for Intel Kabylake VP9 and recent Wayland/EGL regression as they are simple and the later may eventually be fixed upstream. Without vdpau wrapper, NVIDIA GPUs through nouveau also works on X11/Wayland session, though the quality and performance of 3D rendering (especially games) are not on-par with the propriety blobs. No one can rest be assured that regression won't take place at Chromium, MESA or anything else down the road but this is not the reason to avoid VA-API build. The rolling update model itself always open to risk of regression that slipped through verification.

In summary, enabling VA-API build with `use_vaapi= true` does not lead to completely unstable browser. Once `--ignore-gpu-blacklist` is removed, the browser remains as stable as it should be. The browser's GPU compositing remains valid as long as the GPU/driver combo is not in the blacklist. All recent Intel, AMD and NVIDIA GPUs are in the whitelist for GPU compositing. If the GPU/driver combo is already on the blacklist, then using `--ignore-gpu-blacklist` to force the browser into GPU compositing is always unstable regardless of VA-API.

Last edited by liewkj (2020-06-19 11:33:36)

CarbonChauvinist · 2020-06-19 12:46:10

I've been watching the latest developments in this thread with some interest. I don't really have anything to add except for the following:

1. I appreciate the work that both @liewkj and @akarshanbiswas have put in to get VAAPI to work on chromium and firefox respectively (as an aside I've since personally moved to ff-nightly as that just plain works for my needs and use cases on a wayland+plasma stack).

2. I've also been meaning to ask @liewkj in this thread how you've been coming along on the proposal to implement EGL_ANGLE_sync_control_rate in MESA. The devs seemed very open to your contribution and it appears they are just waiting on the results of testing? Is this something you are still working on?

primeos · 2020-06-19 13:02:37

Quick FYI: I've opened an upstream issue about building with VA-API support on Linux by default: https://bugs.chromium.org/p/chromium/is … id=1097029 (please don't "spam" this issue, as it's a technical bug tracker, but feel free to add any relevant information).
I'm not too optimistic that use_vaapi will default to true anytime soon but I'm not aware of any prior upstream discussion regarding this (all prior discussions where also about enabling it at runtime which is what caused all of these problems in the past).

(Note: I'm not a Chromium developer and the issue text is probably far from perfect but let's see where it leads us and how upstream feels about this.)
(Edit: And thanks for this valuable thread and the awesome work of the chromium-vaapi AUR team.)

Last edited by primeos (2020-06-19 13:05:21)

sadboi777 · 2020-06-19 13:40:45

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

Does hardware-video decoding still work with those flags disabled?

eschwartz · 2020-06-19 13:54:25

So y'all keep saying that "things have changed, you don't need a patch anymore to enable it", but I don't really know or care what some AUR package does.

I do, however, know that the official extra/chromium package dropped a patch chromium-enable-mojo-video-decoders-by-default.patch because it was merged upstream, and I'm not talking about that patch, even though it too contained "#if defined(OS_LINUX)" diff hunks.

I'm talking about the patches which were present in the *last* version of extra/chromium to have vaapi enabled.

chromium-vaapi.patch: Enable mojo with VDA2 on Linux

This includes changes to:

- gpu/config/software_rendering_list.json

-       "id": 48,
--      "description": "Accelerated video decode is unavailable on Linux",
-+      "description": "Accelerated VA-API video decode is not supported on NVIDIA platforms",
-       "cr_bugs": [137247],
-       "os": {
-         "type": "linux"
-       },
-+      "vendor_id": "0x10de",
-       "features": [
-         "accelerated_video_decode"

- chrome/browser/about_flags.cc

define and create the flags disable-accelerated-video-decode and disable-accelerated-mjpeg-decode

I checked this before posting about how you still need patches. The changes still apply to refs/head/master of the chromium.googlesource.com source code. Not only is it seemingly enabled by default which was a "break it by default" experience in the past, you need to patch the source code to even enable options that let you turn it off at runtime. @maximbaz posted about exactly this last year and said it wasn't worth adding downstream patches to add options for turning it off, in the chromium-vaapi opt-in package. So that might explain why you're looking at the chromium-vaapi package and deducing that no patches are needed.

seth wrote:

The benign reason: "We think this is generally buggy, but can say that it works on certified chromebooks, thus it's enabled on this system"
The conspiracy theory on that explanation is that google seeks world domination through chromeos or something like this. Not kidding, no.

This.

I believe in the benign reason, to be exact. More specifically, my impression was that chromium was... resistant... to paying attention to bug reports about non-certified devices, most likely because they simply didn't care. So you might be able to get it to work, but only if you provide a perfect patch to do it, for which you're on your own.

liewkj · 2020-06-19 20:36:41

eschwartz wrote:

I do, however, know that the official extra/chromium package dropped a patch chromium-enable-mojo-video-decoders-by-default.patch because it was merged upstream, and I'm not talking about that patch, even though it too contained "#if defined(OS_LINUX)" diff hunks.
I'm talking about the patches which were present in the *last* version of extra/chromium to have vaapi enabled.
chromium-vaapi.patch: Enable mojo with VDA2 on Linux
I checked this before posting about how you still need patches. The changes still apply to refs/head/master of the chromium.googlesource.com source code. Not only is it seemingly enabled by default which was a "break it by default" experience in the past, you need to patch the source code to even enable options that let you turn it off at runtime.

Frankly, if you refused to look at the AUR and kept on harping on the past, then there was nothing more I could say. You repeatedly brought on the past and hardened assumption and yet not even willing to open up your own mind and eyes. Well, it's good that you had confessed that you dislike Chromium, fair enough . I hope Firefox picking up VA-API on Wayland will make you happy and I wish they deliver the commitment to support X11 before the end of the world.

Everything you had said above, was in the past and I was on your side. The *last* version of extra/chromium which had VA-API enabled was attempted at the wrong moment with the wrong patch. I wish I could stop reiterating that. I knew both the past and the presence while you only knew the past, refused to *look at* the presence and yet kept on implying the past remains the same AS-IS. I am sorry to say that you are so wrong about it but you probably didn't care.

eschwartz wrote:

I believe in the benign reason, to be exact. More specifically, my impression was that chromium was... resistant... to paying attention to bug reports about non-certified devices, most likely because they simply didn't care. So you might be able to get it to work, but only if you provide a perfect patch to do it, for which you're on your own.

You have your viewpoint, but in the business world, how could anyone be different? Prioritizing bugs on certified devices is the natural business model, and when the bugs do affect certified devices, then they will heed.

eschwartz · 2020-06-19 20:46:47

liewkj wrote:

Frankly, if you refused to look at the AUR and kept on harping on the past, then there was nothing more I could say. You repeatedly brought on the past and hardened assumption and yet not even willing to open up your own mind and eyes. Well, it's good that you had confessed that you dislike Chromium, fair enough . I hope Firefox picking up VA-API on Wayland will make you happy and I wish they deliver the commitment to support X11 before the end of the world.
Everything you had said above, was in the past and I was on your side. The *last* version of extra/chromium which had VA-API enabled was attempted at the wrong moment with the wrong patch. I wish I could stop reiterating that. I knew both the past and the presence while you only knew the past, refused to *look at* the presence and yet kept on implying the past remains the same AS-IS. I am sorry to say that you are so wrong about it but you probably didn't care.

"The changes still apply to refs/head/master of the chromium.googlesource.com source code"

Please, if my conclusion is wrong, tell us all why "the changes still apply to master" is not relevant. I completely don't care whether you think I'm "harping on the past", I'm entirely focused on just caring what the upstream code says in the present.

I promise you it won't hurt my feelings if you explain why this patch is obsolete (and conveys misleading information, apparently).

liewkj wrote:

eschwartz wrote:
I believe in the benign reason, to be exact. More specifically, my impression was that chromium was... resistant... to paying attention to bug reports about non-certified devices, most likely because they simply didn't care. So you might be able to get it to work, but only if you provide a perfect patch to do it, for which you're on your own.
You have your viewpoint, but in the business world, how could anyone be different? Prioritizing bugs on certified devices is the natural business model, and when the bugs do affect certified devices, then they will heed.

It can be and is different all the time. For people who produce a product which is intended and advertised as being useful for lots of people including me, the usual expectation is that they devote effort to heeding my needs if they want me to use it.

If Chromium does not heed VA-API bugs for linux users, the logical conclusion is they don't consider us their target market, and we should be wary of using it.

If they're heeding bugs then that's great news and I guess they've come around to the idea of us being their target market...

I'm not sure why this is so hard to understand, or why it is necessary to apologize for some corporation not caring about Linux users because it isn't their business model. I never said they were bad human beings, and I never said I was surprised by their goals either. I simply pointed out that it *is* their goals, and those goals impact the goals of Linux users.

Last edited by eschwartz (2020-06-19 20:56:25)

liewkj · 2020-06-19 21:56:20

eschwartz wrote:

"The changes still apply to refs/head/master of the chromium.googlesource.com source code"
Please, if my conclusion is wrong, tell us all why "the changes still apply to master" is not relevant. I completely don't care whether you think I'm "harping on the past", I'm entirely focused on just caring what the upstream code says in the present.
I promise you it won't hurt my feelings if you explain why this patch is obsolete (and conveys misleading information, apparently).

Your understanding of that patch is all wrong. MojoVideoDecoder is the factory that manages hardware accelerated video decoders. It was enabled by default to manage video decoding instead of the old GPUVideoDecoder prior to Chromium-71. It does not break anything with `use_vaapi=true`. Please read the commit message carefully. I put it here for you, highlighting key messages that you had stubbornly refused to accept the presence.

https://chromium-review.googlesource.co … /+/1370717

Enable mojo video decoders by default on Linux desktop if use_vaapi is true
Already the case for ChromeOS, Mac and Win. And run the service
in the GPU process too. Except that here the gn arg use_vaapi
has to be true as well.
Note that this CL does not change the following:
- the gn arg 'use_vaapi' is still false by default on Linux,
see media/gpu/args.gni
- 'accelerated_video_decode' is still black listed on Linux,
see entry 48 in gpu/config/software_rendering_list.json
- it is still not possible to enable hw video decode from
about:flags, see chrome/browser/about_flags.cc
Also note that with this CL the ffmpeg and libvpx video decoders
are still selected thanks to media::DecoderSelector::SelectDecoder
in case vaapi fails to initialize.
Also see https://chromium-review.googlesource.co … +/1225275/
which was very similar but for ChromeOS.
Tested on Linux desktop with gn args:
- use_vaapi = true (default is false)
./out/release/chrome --ignore-gpu-blacklist --use-gl=desktop

Without `--ignore-gpu-blacklist`, VA-API cannot be enabled. Period. All these information have always been in the light. Google/Chromium did a great job at documenting them. While Ubuntu, Fedora in the past might have manipulated their own patch to enable VA-API by default, this was not what I was pushing for extra/chromium.

eschwartz wrote:

If Chromium does not heed VA-API bugs for linux users, the logical conclusion is they don't consider us their target market, and we should be wary of using it.

They did heed VA-API bugs. VA-API is now universal with both Intel and AMD backing. Sure if one nagged about NVIDIA GPUs support, well, it is understood why they don't care. Be glad that Chromium needs Linux as a test vehicle for VA-API, too. When the bugs are genuine VA-API issues, they will affect both Linux and ChromeOS.

viggy96 · 2020-06-20 15:03:45

It looks like this has been implemented!
https://bugs.archlinux.org/task/65886

This is a great thing!!!

dimischiavone · 2020-06-20 15:40:56

viggy96 wrote:

It looks like this has been implemented!
https://bugs.archlinux.org/task/65886
This is a great thing!!!

This is a really great thing, on my laptop this took huge amount of time to build (i didn't trust the chinese archlinuxcn repo). Unfortunately, for my amd apu (vega 10), the current mesa (20.1.1-1) still has issues with hardware video decoding 4k videos and 60 fps video on youtube.

Last edited by dimischiavone (2020-06-20 15:41:47)

digitalone · 2020-06-21 09:26:25

I tried both Chromium and Firefox hardware acceleration on Gnome Wayland. Firefox has resolved their serious issues, but I still get flickering sometimes, while Chromium is always stable during playback, never get flickering. Using chromium-vaapi from years, had issues in the past, but the latest builds are very stable. I hope this could be available upstream.

edit: flickering issue for Firefox should be completely fixed in version 78, now I'm using 77. Anyway at this time Chromium is more stable. It's also available on X11, but that's not an advantage for me, I'm on Wayland.

Last edited by digitalone (2020-06-21 09:48:59)

once · 2020-06-21 10:56:43

with - use_vaapi = true build, how can tell it work or not?

digitalone · 2020-06-21 22:27:22

Testing now on Chromium I noticed that unfortunately 1080p6o playback has issues. It freezes regularly. No issues with other formats. Maybe the only hope to get everything good is the next Firefox version.

Last edited by digitalone (2020-06-21 22:28:28)

liewkj · 2020-06-21 23:33:18

I finally wrest Ryzen 2500U APU notebook back from my kids. Promised to get him a 3500u at replacement.
I tried the same video I mentioned before, this time at 1080p@60 VP9 and it played flawlessly without a single dropped frame.

liewkj wrote:

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

digitalone wrote:

Testing now on Chromium I noticed that unfortunately 1080p6o playback has issues. It freezes regularly. No issues with other formats. Maybe the only hope to get everything good is the next Firefox version.

Can you also provide the link to the sample video you tried? You mentioned that you are on Wayland, but since you are on AMD it is unaffected. However, if you want to checkout if `--use-gl=egl` would make things better because EGL is native language on Wayland, then you still need to get chromium-vaapi AUR and make your own MESA package to include the EGL_ANGLE_sync_control_rate implementation.

Or, you can also check out ungoogled-chromium AUR, the maintainer is more responsive and open-minded than chromium-vaapi AUR ever since MaximBaz left.

oiler1729 · 2020-06-22 00:23:08

I have set up hardware acceleration with intel-media-driver and the precompiled chromium-vaapi from archlinuxcn on my iHD 620, here is my vainfo:

vainfo: VA-API version: 1.7 (libva 2.7.1)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 20.1.1 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   : VAEntrypointVideoProc
      VAProfileNone                   : VAEntrypointStats
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Simple            : VAEntrypointEncSlice
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointFEI
      VAProfileH264Main               : VAEntrypointEncSliceLP
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointFEI
      VAProfileH264High               : VAEntrypointEncSliceLP
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline: VAEntrypointFEI
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointFEI
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD

Video playback is hardware accelerated and uses a lot less cpu, however I've noticed that in chrome://gpu, Vulkan and Out of Process Rasterization are marked as disabled. I was curious as to whether Vulkan rendering or Out of Process Rasterization offers better performance, as it seems that as noted here https://linuxreviews.org/Chromium_81_Is … Enabled%20, Vulkan rendering does not work with hardware acceleration for video playback (strangely it works with libva-intel-driver but not intel-media-driver). Is it better to enable Vulkan and Out of Process Rasterization or leave them off?

Last edited by oiler1729 (2020-06-22 00:32:59)

digitalone · 2020-06-22 07:57:07

liewkj wrote:

Can you also provide the link to the sample video you tried?

Everything marked as 1080p60 on Youtube (h264ified) and Twitch.

liewkj wrote:

You mentioned that you are on Wayland, but since you are on AMD it is unaffected. However, if you want to checkout if `--use-gl=egl` would make things better because EGL is native language on Wayland

This flag worked in the previous chromium-vaapi build, but now is broken and the playback falls back to software decoding.

liewkj wrote:

then you still need to get chromium-vaapi AUR and make your own MESA package to include the EGL_ANGLE_sync_control_rate implementation.

And how can I include this implementation? Why is it not included by default?

liewkj · 2020-06-22 18:55:28

once wrote:

with - use_vaapi = true build, how can tell it work or not?

Google is your friend. Search with keyword `chromium vaapi`. There are tons of articles/blogs that show you how to verify VA-API in action.

oiler1729 wrote:

Is it better to enable Vulkan and Out of Process Rasterization or leave them off?

You decide it for yourself. They can be enabled from `chrome://flags`.

digitalone wrote:

This flag worked in the previous chromium-vaapi build, but now is broken and the playback falls back to software decoding.

Upstream Chromium broke it.
https://bugs.chromium.org/p/chromium/is … id=1071550

digitalone wrote:

And how can I include this implementation? Why is it not included by default?

Cast your vote if you care. It's the damned Wayland, and not everyone is on that side.
https://bugs.archlinux.org/task/67035

digitalone · 2020-06-22 21:07:46

I'll wait for Firefox 78. If it works (it should, dev fixed the stuttering issue), I don't care about Chromium.

digitalone · 2020-06-25 21:06:42

I installed lts kernel and surprisingly chromium-vaapi is working good on wayland with all formats, even 1080p60 h264.

It's a kernel issue then. I'll keep using linux-lts.

Arch Linux

#351 2020-06-19 02:47:34

Re: chromium: hardware video acceleration with VA-API

#352 2020-06-19 02:51:24

Re: chromium: hardware video acceleration with VA-API

#353 2020-06-19 03:11:17

Re: chromium: hardware video acceleration with VA-API

#354 2020-06-19 05:47:39

Re: chromium: hardware video acceleration with VA-API

#355 2020-06-19 08:33:06

Re: chromium: hardware video acceleration with VA-API

#356 2020-06-19 10:01:57

Re: chromium: hardware video acceleration with VA-API

#357 2020-06-19 11:20:27

Re: chromium: hardware video acceleration with VA-API

#358 2020-06-19 12:46:10

Re: chromium: hardware video acceleration with VA-API

#359 2020-06-19 13:02:37

Re: chromium: hardware video acceleration with VA-API

#360 2020-06-19 13:40:45

Re: chromium: hardware video acceleration with VA-API

#361 2020-06-19 13:54:25

Re: chromium: hardware video acceleration with VA-API

#362 2020-06-19 20:36:41

Re: chromium: hardware video acceleration with VA-API

#363 2020-06-19 20:46:47

Re: chromium: hardware video acceleration with VA-API

#364 2020-06-19 21:56:20

Re: chromium: hardware video acceleration with VA-API

#365 2020-06-20 15:03:45

Re: chromium: hardware video acceleration with VA-API

#366 2020-06-20 15:40:56

Re: chromium: hardware video acceleration with VA-API

#367 2020-06-21 09:26:25

Re: chromium: hardware video acceleration with VA-API

#368 2020-06-21 10:56:43

Re: chromium: hardware video acceleration with VA-API

#369 2020-06-21 22:27:22

Re: chromium: hardware video acceleration with VA-API

#370 2020-06-21 23:33:18

Re: chromium: hardware video acceleration with VA-API

#371 2020-06-22 00:23:08

Re: chromium: hardware video acceleration with VA-API

#372 2020-06-22 07:57:07

Re: chromium: hardware video acceleration with VA-API

#373 2020-06-22 18:55:28

Re: chromium: hardware video acceleration with VA-API

#374 2020-06-22 21:07:46

Re: chromium: hardware video acceleration with VA-API

#375 2020-06-25 21:06:42

Re: chromium: hardware video acceleration with VA-API

Board footer