Package Details: chromium-vaapi 71.0.3578.98-1

Git Clone URL: (read-only)
Package Base: chromium-vaapi
Description: Chromium with VA-API support to enable hardware acceleration
Upstream URL:
Keywords: browser web
Licenses: BSD
Conflicts: chromium
Provides: chromium
Submitter: samcv
Maintainer: OneObsession (maximbaz)
Last Packager: maximbaz
Votes: 62
Popularity: 4.552630
First Submitted: 2016-07-09 09:44
Last Updated: 2018-12-13 21:31

Dependencies (48)

Required by (37)

Sources (8)

Pinned Comments

Terence commented on 2018-11-13 23:15

[Nvidia users PLEASE READ]

To get hardware acceleration working, you also have to install

Disclaimer : VP8/9 video decoding will not work!

GeForce GTX 750 SE and after support HEVC and VP9 video decoding but VDPAU,the only VAAPI backend available for Nvidia users with libva-vdpau-driver, doesn't support VP8/9.

4 ways to solve this:

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

ForeignCon commented on 2018-12-07 12:38

@axfelix Actually, there used to be VaapiDrmPicture class only. This year they broke the class into several sub classes which look like:

  |   VaapiPicture  |
  ^                 ^
  | =vaapi-drm=     +----+ =xorg(vaapi-glx)=
  +--------------+       +------------------+
  | VaapiPicture |       | VaapiPictureTFP  |
  | NativePixmap |       | (This is default)|
  +--------------+       +------------------+
   |                         |
 +-------+               +-------+
 | VPNP  |               | VPNP  |
 | Ozone |               | Egl   |
 +-------+               +-------+

*VPNP is Vaapi Picture Native Pixmap. I believe somewhere these sub classes(esp. VPNP ozone) are not being included during building and this is what causes the error during linking. I may be wrong because when I see the source I can't find anything unusual. That's why I'm trying to build it with use_ozone=true ozone_platform_gbm=true use_intel_minigbm=true and use_egl=true to include the whole set of those drm classes. I am not confident with this anyway tbh.

axfelix commented on 2018-12-07 04:17


So I guess there's one Google employee trying to get the chromeOS GPU raster paths working on Linux, but they conflict with the out of tree Linux chromium GPU video decoding patches maintained by a different Google employee :) Thanks for trying!

ForeignCon commented on 2018-12-06 04:55

@axfelix I have tried this, Build fails with this error:

./../media/gpu/vaapi/ error: undefined reference to 'media::VaapiPictureNativePixmapOzone::VaapiPictureNativePixmapOzone(scoped_refptr<media::VaapiWrapper> const&, base::RepeatingCallback<bool ()> const&, base::RepeatingCallback<bool (unsigned int, unsigned int, scoped_refptr<gl::GLImage> const&, bool)> const&, int, gfx::Size const&, unsigned int, unsigned int, unsigned int)'
collect2: error: ld returned 1 exit status

maximbaz commented on 2018-12-04 10:53

axfelix: don't think so, am I right to understand that such build would only work on Intel GPUs? If you want to try, send me a patch to PKGBUILD and I can build it for you, in exchange you test the build and compare with current chromium and report back the results ;)

axfelix commented on 2018-12-04 06:16

Have we tried building with "--args=use_ozone=true ozone_platform_gbm=true use_intel_minigbm=true" lately per I understand that all of the relevant libminigbm stuff has been merged into Arch Mesa so there shouldn't be any weird dependencies to support at this point...

maximbaz commented on 2018-11-23 19:07

laenco: thanks for letting me know about jumbo builds, it was an interesting read. In fact, it reduces the build time from 4 hours to 1.5 hours on my machine ;) However I confirmed with foutrelis (who maintains extra/chromium), the reason we don't enable jumbo builds is the possibility of "Silent use of unintended variable" described in here.

I'd like to keep this PKGBUILD as close as possible to extra/chromium, so if you want to enable jumbo builds, feel free to add that flag in your own copy of PKGBUILD.

nperic commented on 2018-11-23 17:43

My build failed without system python protobuf (didn't catch the error, sorry), so I modified the PKGBUILD to include it. Not sure if it's the right thing to do, just wanted to share the info.

@@ -23,7 +23,7 @@ depends=('gtk3' 'nss' 'alsa-lib' 'xdg-utils' 'libxss' 'libcups' 'libgcrypt'
 makedepends=('python' 'python2' 'gperf' 'yasm' 'mesa' 'ninja' 'nodejs' 'git'
-             'clang' 'lld' 'gn')
+             'clang' 'lld' 'gn' 'python-protobuf' 'python2-protobuf')
 optdepends=('pepper-flash: support for Flash content'
             'kdialog: needed for file dialogs in KDE'
             'gnome-keyring: for storing passwords in GNOME keyring'

francoism90 commented on 2018-11-21 08:39

@Inixi I don't think this package depends on this. What happens when you uninstall libva-intel-driver and only install the intel-media-driver?

Inixi commented on 2018-11-21 07:15

@maximbaz, is there a possibility to use intel-media-driver instead of libva-intel-driver? According to it has better support for higher resolutions. For instance on libva I am able to watch 4K videos on youtube but 8K videos are not accelerated - seems like libva does not provide support for that.

clap22 commented on 2018-11-14 16:31

@maximbaz really weird, also get this in the kernel along with the build fail:

traps: protoc_plugin[6874] trap invalid opcode ip:218598 sp:7ffd125c35d0 error:0 in protoc_plugin[213000+a5000]

My only suspect dependency is llvm8-svn, but last version compiled fine with it.

edit: Solved after I downgraded llvm/clang to 7. Probably a new bug introduced in llvm.