Package Details: libva-vdpau-driver-vp9-git r57.509d3b2-4

Git Clone URL: (read-only, click to copy)
Package Base: libva-vdpau-driver-vp9-git
Description: VDPAU backend for VA API. (Version with VP9 codec support)
Upstream URL:
Keywords: chromium vaapi vdpau vp9
Licenses: GPL
Conflicts: libva-vdpau-driver, nvidia-vaapi-driver
Provides: libva-vdpau-driver
Replaces: vdpau-video
Submitter: Terence
Maintainer: Terence (xuanruiqi)
Last Packager: Terence
Votes: 16
Popularity: 0.88
First Submitted: 2020-01-27 20:21 (UTC)
Last Updated: 2022-01-04 21:58 (UTC)

Required by (18)

Sources (1)

Latest Comments

pc00per commented on 2022-07-22 11:24 (UTC)

@urbenlegend Right now the only way of hw decoding on a wayland session, is on firefox-beta with nvidia-vaapi-driver with the instructions provided in readme. It's funny that it doesn't use vdpau, but directly utilizes nvdec through nvidia-libs.

urbenlegend commented on 2022-07-22 05:43 (UTC)

@pc00per Using the flags you listed I was able to get VDAVideoDecoder to be used. Unfortunately, the --use-gl=desktop flag really messes with the browser framerate. It lowers my framerate from 120Hz to a weird stutery 45-50hz. If I don't use the --use-gl flag then all I get is a black screen. So close, but no cigar.

pc00per commented on 2022-06-28 22:02 (UTC)

@xuanruiqi @Terence Any chance whether it works on wayland ?

pc00per commented on 2022-06-10 22:33 (UTC) (edited on 2022-06-24 11:02 (UTC) by pc00per)

@DAC324 Ya you're right. It's blank without gl. ANGLE seems to mess with decoding here. Also had to explicitly --use-vulkan. Turning vulkan from the flags section seems to mess with acceleration.

DAC324 commented on 2022-06-10 17:18 (UTC) (edited on 2022-06-10 17:21 (UTC) by DAC324)

@pcooper Thank you very much for that update.

As for your previous quote

No need of use-gl=egl or desktop to disable ANGLE (unless you're on wayland) or forced gpu rasterization in general.

At least here, I need use-gl=desktop as otherwise, there will be no picture in the videos, they remain black with only audio being played. Also, --use-vulkan can be left enabled, it does not make any difference here.

pc00per commented on 2022-06-10 13:38 (UTC) (edited on 2022-06-24 11:06 (UTC) by pc00per)

@DAC324 Finally fixed it. Some notes to consider to successfully get a working VDAVideoDecoder.

  • Don't disable SkiaRenderer.
  • Must disable ChromeOSDirectVideoDecoder.

DAC324 commented on 2022-06-03 07:57 (UTC) (edited on 2022-06-03 08:18 (UTC) by DAC324)

@pcooper: That's no surprise. Just check for video codec support. You will encounter that the RTX3090 fully supports VP9 decoding.

The problem here is the difference between NVDEC and VDPAU. Chromium currently does not seem to support NVDEC but VDPAU (via this driver package here) instead. As already discussed however, this driver package lacks VP9 support to some extent.

Here's a better link about video codecs and hardware support:

Of note, Nvidia very much likes to confuse its customers by their product numbering schemes. Great example: A GeForce GTX 750 Ti is not as one might guess a special edition of a GeForce GTX 750 but in fact, even inferior. While the GeForce GTX 750 is "Maxwell 2nd Generation", the GeForce GTX 750 Ti is "Maxwell 1st Generation" only, lacking a lot of support that the later chipsets have.

Fortunately, there is the chip number which appears to be still logical, with higher numbers indicating superior chipsets. So, instead of using that misleading product numbering scheme ("GeForce XXX Super Duper Whatever"), you must have a look at the chipset being actually used, and go from there.

pc00per commented on 2022-06-02 20:43 (UTC)

@DAC324 But this guy 3 months ago showed VDAVideoDecoder as working perfectly ( on his 3090. It's strange how he has got that kind of setup, as I've tried everything to get there but failed.

DAC324 commented on 2022-06-02 17:41 (UTC) (edited on 2022-06-02 18:27 (UTC) by DAC324)

@pcooper: The reason for that is surprisingly simple: Full VP9 hardware acceleration is only supported on GeForce GTX 1650 / MX450 or newer. Everybody having an older card, cannot use hardware acceleration for VP9 video playback, at least not on higher bit depths.


Since I have an Nvidia NVIDIA GeForce GTX 750 Ti which at least supports 8-bit VP9 hardware acceleration, I apparently was misled previously by testing with inappropriate video specs :(

pc00per commented on 2022-05-25 10:59 (UTC) (edited on 2022-05-25 10:59 (UTC) by pc00per)

@DAC324 There are still some users today who claim to have a working vp9 browser acceleration, but don't exactly tell us how they achieved on their Nvidia card...¯\_(ツ)_/¯

DAC324 commented on 2022-05-25 10:54 (UTC) (edited on 2022-05-25 10:55 (UTC) by DAC324)

@pcooper: chromium-vaapi is no longer needed as the VAAPI patch has made it in the stock Chromium.

If my memory serves me right, I already had VP9 hardware accelerated video decode working in Chromium but apparently, it got broken again. By the way, it does not matter if I have libva-vdpau-driver-chromium or libva-vdpau-driver-vp9 installed - it simply does not work anymore :(

pc00per commented on 2022-05-25 10:26 (UTC)

I donno how this is possible. AUR version of chromium-vaapi does not even compile. It's even flagged outdated. I donno what other browsers come with vaapi supported, I've literally tried every browser from pacman, aur binary, snap & flathub repos too. None of them have working vp9 Decoder (atleast for me). Tried searching every corner of the internet & Nvidia Linux forum discussions. Tried all kinds of flags, enabling vaapi, gl desktop, disabling ozone, etc etc. It's always been VpxVideoDecoder for me.

DAC324 commented on 2022-05-25 09:39 (UTC) (edited on 2022-05-25 09:40 (UTC) by DAC324)

No VP9 support in Chromium with this driver:

As soon as a VP9 video is opened, VpxVideoDecoder is chosen (i.e.,software decoding).

00:00:00.136    info    "Failed to initialize DecryptingVideoDecoder"
00:00:00.136    info    "Failed to initialize VDAVideoDecoder"
00:00:00.137    kIsVideoDecryptingDemuxerStream false
00:00:00.137    kVideoDecoderName   "VpxVideoDecoder"
00:00:00.137    kIsPlatformVideoDecoder false
00:00:00.137    info    "Selected VpxVideoDecoder for video decoding, config: codec: vp9, profile: vp9

Hardware accelerated video decoding currently only works for h.264 videos, using VDAVideoDecoder. There is VAAPIVideoDecoder available for Linux, but it just does not work (yet?). See for a discussion about it.

pc00per commented on 2022-04-30 23:10 (UTC) (edited on 2022-04-30 23:14 (UTC) by pc00per)

@gardotd426 The last time you showed your decoder information ( was probably using VDAVideoDecoder. Mine's using VPXVideoDecoder ( So I'm not sure how I progress further to resolve this issue.

MarsSeed commented on 2022-03-30 08:49 (UTC)


This should conflict with libva-nvidia-driver and nvidia-vaapi-driver-git.

Both are created from the same source and both provide like this package.

The difference of course is that this package is a VA-API frontend with VDPAU backend, while the above mentioned two are VA-API frontends with NVDEC backend and therefore are NVIDIA-only.

pc00per commented on 2022-02-05 21:01 (UTC)

@gardotd426 Ah I've forgot to pass --enable-features=VaapiVideoDecoder to chromium. Apologize for this mate XD.

gardotd426 commented on 2022-02-02 06:17 (UTC)

@pcooper yes man, I've been using this project/package for over a year and a half, since you also needed chromium-vaapi before the regular Chromium, Chrome, and Brave repo packages supported vaapi GPU video decoding. I have GreenWithEnvy up at all times on my second monitor, and can literally watch the Decoder % bar go from 0% to 5-10% (depending on which resolution I'm watching the video at). These videos are in 1440p or 4K, which H264 doesn't support. This project doesn't work with av1. So it can only be vp9, but just to double the confirmation, I've regularly (including 6 times today on 6 different videos) checked the "Stats for Nerds" on YouTube and saw that it was using VP9 while it was being hardware-decoded.

To triple confirm, I've also used the developer tools to confirm that the video decoder is VDAVideoDecoder and that "Hardware Decoder" says "true."

Here you go, look for yourself:

I hope that settles that question, because I mean, it's objective proof using every possible metric.

pc00per commented on 2022-02-02 03:43 (UTC)

@gardotd426 you sure you played vp9 streams specifically?

gardotd426 commented on 2022-02-02 03:41 (UTC)

@pcooper no, I can't reproduce. GPU accelerated video decode is working on YouTube with Chromium, Brave, and Chrome. Just checked.

What are your flags in ~/.config/chromium-flags.conf? Or are you using any flags at all? If not, then what have you set in chrome://flags?

pc00per commented on 2022-02-02 00:18 (UTC)

I got broken white screen in youtube while decoding vp9. Anyone got the same? What's the solution for this?

Kerriganx commented on 2022-01-23 13:08 (UTC)

If someone have high frame rate monitor (for example 144 or 165 Hz) and experiencing chromium bug 1200167 I made aur package for temporary solution.

gardotd426 commented on 2022-01-13 06:42 (UTC)

Shit. My bad, you're correct. However VDPAU AV1 decode support was added to 510, so it should be trivial to add to this driver, and decoding any AV1 videos in something like VLC or MPV should use hardware decoding now.

But IIRC, using this package, h264 didn't work with video decode previously, it only worked if the codec was VP9. Now it works with H264 too (without h264ify).

Shished commented on 2022-01-13 06:35 (UTC)

avc1 is H264 afaik.

gardotd426 commented on 2022-01-13 06:33 (UTC)

So, some awesome (in my opinion) news.

I don't know if this package is required for this or not, but now starting with the new 510 branch Nvidia driver, even AV1 decode use GPU accelerated video decoding. I just pulled up an AV1 test video (and confirmed it was using "avc1" as the codec in the "Stats for nerds" option), and sure enough it instantly used GPU decoding as confirmed by GreenWithEnvy.

So it's not just VP9 now, even AV1 uses hardware video decoding on Nvidia. I think this is amazing news.

gardotd426 commented on 2022-01-04 23:28 (UTC)

I mean the audiences are completely conflicting. nvidia-vaapi-driver is for people that want to attempt to use VAAPI to get hardware accelerated video decode in Firefox specifically (and pretty much nothing else).

Meanwhile, libva-vdpau-driver-vp9-git is for people that want hardware-accelerated video decode in Chrome/Chromium/Brave, and not just for YouTube, but for things like Stadia, GeForceNOW, Xcloud, etc.

How many people fall into both camps? How many people use both chrome and firefox in the first place? Basically you're going to be in either one use-case or the other, and never both, so considering that, and considering that removing the symlink (instead of making the packages conflict) would mean that all users would now have to use an ENVVAR to get HW accel video decode in Chromium-based browsers, then my vote-I-don't-have-a-right-to is that these packages are conflicts and not to remove the symlink.

Terence commented on 2022-01-04 22:02 (UTC)

I added it to the conflicts. Let me know if anything else is required or if I need to change this in the future.

afader commented on 2022-01-04 21:21 (UTC)

Can confirm on brief testing that using this driver with vdpau works better than the nvidia-driver-vaapi-git for now.

gardotd426 commented on 2022-01-04 19:53 (UTC)

After further investigation, I think Terence should add a "conflict" with that new package, until it's actually in a remotely stable state. The GitHub for nvidia-vaapi-driver itself says:

This is an VA-API implementation that uses NVDEC as a backend. This implementation is specifically designed to be used by Firefox for accelerated decode of web content, and may not operate correctly in other applications.

It's currently in early development, so don't expect it to work well.

And it's explicitly for Firefox, and nothing else.

Until it's ready, it should be added as a conflict, and maybe when it's actually production-ready (if that ever happens), the symlink can be removed

gardotd426 commented on 2022-01-04 19:53 (UTC)

After further investigation, I think Terence should add a "conflict" with that new package, until it's actually in a remotely stable state. The GitHub for nvidia-vaapi-driver itself says:

This is an VA-API implementation that uses NVDEC as a backend. This implementation is specifically designed to be used by Firefox for accelerated decode of web content, and may not operate correctly in other applications.

It's currently in early development, so don't expect it to work well.

And it's explicitly for Firefox, and nothing else.

Until it's ready, it should be added as a conflict, and maybe when it's actually production-ready (if that ever happens), the symlink can be removed

gardotd426 commented on 2022-01-04 19:00 (UTC)

@huyz and what exactly would this accomplish? What is the purpose of nvidia-driver-vaapi-git? What functionality does it provide that wasn't there before? And if it's really a VAAPI driver, does it enable hardware decoding in browsers that support it? What's the point?

huyz commented on 2022-01-04 14:27 (UTC)

Feature request: remove the symlink "/usr/lib/dri/".

Now there's a NVDEC backend vaapi driver. (AUR package nvidia-vaapi-driver-git)

This driver still works by setting env LIBVA_DRIVER_NAME=vdpau when remove that symlink.

Terence commented on 2021-10-23 15:59 (UTC)

Thank you very much @xuanruiqi!

xuanruiqi commented on 2021-10-12 18:09 (UTC)

@Terence: I would like to kindly request you to switch to my fork. This has the needed fixes and is actively maintained.

Also, it would be really helpful if you could add me as a maintainer.

xuanruiqi commented on 2021-10-12 17:41 (UTC)

I don't think there is a "fork" of any kind. The PR author just wants commit a fix. But you are right, maybe I should fork the project...

gardotd426 commented on 2021-10-09 19:22 (UTC)

@xuanruiqi actually I think this package should just be moved over to the fork itself. The original is clearly no longer maintained (the creator hasn't even replied to an issue in months I don't think). The original is clearly dead.

xuanruiqi commented on 2021-10-09 18:10 (UTC)

The issue is fixed in this PR. Since the whole PR is just a small commit, I suppose it is also practical to add it as a patch before the repo owner gets to merging it (which might take a long, long time).

Terence commented on 2020-12-23 13:42 (UTC)

This currently does not work with chromium >= 87.

You can subscribe to the issue to be notified of eventual progress here:

but if you do not have anything relevant to add except "me too" please refrain from commenting.

yochananmarqos commented on 2020-12-22 23:38 (UTC)

@gardotd426: I misunderstood, settle down.

gardotd426 commented on 2020-12-22 23:32 (UTC)

Also, enhanced-h264ify provides no real benefit over h264ify in this situation and is irrelevant to this discussion anyway, considering this is the AUR page for libva-vdpau-driver-vp9-git, and we're talking about vp9.

gardotd426 commented on 2020-12-22 23:30 (UTC)

@yochanmarqos why are you asking me if I've used libva-vdpau-driver-chromium while literally directly responding to the sentence where I say libva-vdpau-driver-chromium works if you use h264ify...

yochananmarqos commented on 2020-12-22 23:23 (UTC) (edited on 2020-12-22 23:25 (UTC) by yochananmarqos)

@gardotd426: Have you tried libva-vdpau-driver-chromium? Is there any difference? Also, you should be using enhanced-h264ify, not the original.

gardotd426 commented on 2020-12-22 22:46 (UTC)

This no longer works with Nvidia on Chromium starting in v87.

It works in <=86, but from 87+ it breaks. VP9 videos won't play at all (you get an error).

Using libva-vdpau-driver-chromium with h264ify will allow you to force h264 for some videos and get some hw acceleration, but you're limited to 1080p and it doesn't work a lot of the time, so if this driver could get fixed that would be fantastic.

This is an established/confirmed issue.

yochananmarqos commented on 2020-12-06 15:47 (UTC)

libva is now only a makedepend with libva-vdpau-driver 0.7.4-5.

Terence commented on 2020-11-29 09:27 (UTC)

@DDoSolitary Thanks, added. @Strykar I'm just packaging this so I don't know. It says it supports chromium only in the project page.

DDoSolitary commented on 2020-11-29 04:39 (UTC)

Missing makedepends git

Strykar commented on 2020-08-12 00:33 (UTC) (edited on 2020-08-12 00:33 (UTC) by Strykar)

Would it be possible to get this to work with Arch's community google-chrome-stable package or is this Chromium only?

Terence commented on 2020-07-27 09:41 (UTC)

@securetodeath I don't know, sorry. I'd think it results in the same thing as libva-vdpau-driver-chromium, but implemented differently.

securetodeath commented on 2020-07-25 20:10 (UTC)

Does this package include all the patches from libva-vdpau-driver-chromium as well? They're not in the PKGBUILD, but perhaps they're already applied in the git repo. Quickly browsing it didn't show the exact patches applied though, hence my question.

VxlerieUwU commented on 2020-05-26 21:07 (UTC)

most reliable driver for chrome

Terence commented on 2020-04-19 15:51 (UTC)

@jeois @Shished Thanks for the report, updated.

jeois commented on 2020-04-18 23:57 (UTC)

It seems the upstream maintainer now includes the chromium-fix patch, according to a quick scan of the code. So, there is no need to apply that patch anymore.

Therefore, simply delete the line containing "chromium-fix.patch" in the prepare() function of the PKGBUILD in order to compile/install for use with chromium-vaapi. It still works fine, with the same exceptions as before.

Otherwise, the package will not build like previous comment mentioned.

Shished commented on 2020-04-17 17:31 (UTC) (edited on 2020-04-17 17:32 (UTC) by Shished)

Latest verion does not builds, patch cannot be applied.

patching file src/vdpau_driver_template.h

Reversed (or previously applied) patch detected! Skipping patch.

2 out of 2 hunks ignored -- saving rejects to file src/vdpau_driver_template.h.rej

patching file src/vdpau_video.c

Hunk #1 succeeded at 516 with fuzz 1 (offset 15 lines).

patching file src/vdpau_video.h

Reversed (or previously applied) patch detected! Skipping patch.

1 out of 1 hunk ignored -- saving rejects to file src/vdpau_video.h.rej

Shished commented on 2020-03-12 12:27 (UTC)

This package provides modified libva-vdpau-driver with vp9 decoding added. H264 support is not removed from it.

DAC324 commented on 2020-03-12 12:19 (UTC) (edited on 2020-03-12 12:20 (UTC) by DAC324)

Installing libva-vdpau-driver-vp9-git will remove: libva-vdpau-driver-chromium (libva-vdpau-driver)

This means installing this driver will remove h.264 support provided by libva-vdpau-driver-chromium for nVidia cards, right?

Would there be a way to keep both h.264 and vp9 support in the driver?

Terence commented on 2020-02-02 13:56 (UTC)

Thanks, updated.

Shished commented on 2020-01-28 16:51 (UTC) (edited on 2020-01-28 16:51 (UTC) by Shished)

You need to apply a patch to make it to work in Chromium >= 79