Package Details: chromium-vaapi 71.0.3578.80-1

Git Clone URL: https://aur.archlinux.org/chromium-vaapi.git (read-only)
Package Base: chromium-vaapi
Description: Chromium with VA-API support to enable hardware acceleration
Upstream URL: https://www.chromium.org/Home
Keywords: browser web
Licenses: BSD
Conflicts: chromium
Provides: chromium
Submitter: samcv
Maintainer: OneObsession (maximbaz)
Last Packager: maximbaz
Votes: 60
Popularity: 6.171789
First Submitted: 2016-07-09 09:44
Last Updated: 2018-12-06 20:19

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 https://aur.archlinux.org/packages/libva-vdpau-driver-chromium

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

1 2 3 4 5 6 ... Next › Last »

clap22 commented on 2018-12-08 17:07

A couple of notes:

  • it builds with llvm8-svn again after last 2 releases failing as mentioned before
  • I had system crashes with jumbo build and ryzen hyperthreading enabled. It tried to use too much RAM and hangs. Doesn't happen if I disable SMT or jumbo build. I thought it was an unstable overclock at first but ended up consistently reproducing it @stock and underclocked.

maximbaz commented on 2018-12-08 14:38

Huh, interesting, you are right! Updated my post :P

ArchangeGabriel commented on 2018-12-08 14:27

@maximbaz: Only base-devel, not base. They are no assumption of any kind regarding base anywhere in Arch Linux. ;)

maximbaz commented on 2018-12-08 14:19

andrej: bison is part of base-devel group, and it is always assumed that base-devel group is installed when building AUR packages, check out this wiki page for more info.

andrej commented on 2018-12-08 09:58

I think that this package needs bison in its makedepends. Otherwise it tries to invokem bison and then fails quite early in the build process.

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

@ForeignCon

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/vaapi_picture_factory.cc:74: 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 https://01.org/blogs/joone/2018/using-chrome-os-graphics-stack-intel-based-linux-desktops? 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...