Upstream mesa removal of AVC/HEVC/VC-1 hardware acceleration (AMD GPUs)

No answer is also an answer.
While @winnie stated it is the same on Fedora or openSUSE (as an excuse,maybe), those and also Debian have their non-free repos.
We are let alone with cryptic excuses. Since two days my fresh ordered thinkpad P16s amd is waiting, and I fear manjaro is no longer a good option .

1 Like

Well, isn’t it obvious yet? :smiley:

There is so many distros and so many options I don’t see how what any distro does should be of any concern. Just install whatever serves you best.

Perhaps I fundamentally don’t understand something here
but isn’t openh264 from the normal repos a solution for at least this format?

Or is hardware de/encoding then missing (I don’t think so)?

Intel and Nvidia GPUs use their own hardware-accelerated video decoders for AVC, HEVC, etc.

AMD supposedly relies on mesa for hardware-acceleration of AVC, HEVC, etc.

This means that AMD GPUs will not support hardware-accelerated video decoding for AVC, HEVC, etc, if the version of mesa was compiled without said decoder support. (Fedora, openSUSE, Manjaro, among others?) Thus, such systems will fallback to using the CPU to decode the videos (which is more taxing and can drain more battery for laptop owners.)

1 Like

Thank you very much for that summary!
There more than likely will be a version of mesa with these enabled in the AUR.
I’d not have a problem with that.
I will not have the “problem” anyway, since my hardware is Intel.

I don’t think it’s likely, for two reasons:

  1. Arch’s repository already has mesa with support for these decoders, even in their latest staging branch.

So it looks like Arch Linux will continue to support these decoders via mesa (by their very nature of being “as vanilla as possible” in regards to upstream.) CORRECTION: Looks like Arch is straying from upstream in this case. :hushed: Upstream Mesa is disabling support by default.

The mesa package for Manjaro is intentionally compiled without such decoder support.

There are two versions of mesa in play: Arch and Manjaro

  1. Even if an AUR version is created (to guarantee continued support of these decoders) it would be redundant and possibly introduce breaks in the future if it’s not properly maintained, let alone tested to work with the official repository libraries, dependencies, etc.

Arch Linux users would vehemently oppose such a package in the AUR[1], while Manjaro users would just request their already existing package (in the Manjaro repository) to revert back to how it used to be with full decoder support.

[1] Such a mesa PKGUILD in the AUR would violate their policies. You cannot say it’s a “patched version with extra features” when in fact it’s the exact same version with the exact same features, but you want to submit it for the sake of convenience for Manjaro users.


Why would you want the same PKGBUILD twice anyway? You can download it from arch repo and build that. Or install already built package. If you guys went through so much trouble to have some old 5.24 plasma, this won’t be much of a problem. :smiley:

Why can’t manjaro not have 2 mesa packages:

  1. First one is default and does not support patented codecs
  2. Second one in repos with support for all codecs

As far as I can see, its just a single line difference in pkgbuild, but it would save the effort to recompile for a lot of users, and reduce risk of crashes or bugs with git package and manually compiled packages.

Since the mesa package with codec support is manually installed by user, manjaro is not liable for any of the legal troubles. This would be kind of like what ubuntu does (in terms of making users install the codecs and not including them by default)


excuse my tinkering, but from what i see ATM(important) manjaro in its repo has only custom/overlay build for package ‘mesa’ only out of the entire mesa stack (which is still inherited as is from arch). which makes me think ATM replacing manjaro ‘mesa’ package with arch’s would just work fine, which is very easy.

all this could be very short-lived if more sprodiac changes are introduced in the mesa stack after.

Let me summarize it shortly, so that I do understand it correctly:
Manjaro will be using the Mesa package without the codecs because Manjaro GmbH & Co KG has decided as such? And this decision is done because of (possible) patent infringements which will only affect US based companies (and therefore does not apply to a german GmbH)? And the only two solutions are “waste CPU time and don’t use your 1000times more efficient GPU” or “use AUR” (which is strictly not advised by Manjaro guidelines, which makes sense as AUR is expecting newest versions of depended packages which may be too old due to Manjaros slow rolling release, compared to Arch)?
Any error in this summary?


Strangely intel vaapi drivers are still in repo. Are they not trendy enough to be removed too?

Plus Nvidia is not open-source too, as I know :grin:


Be honest now.

Which one of you was this?

Do you mean @BaronKarza in Manjaro forum?

Idk who the person, but what else was expected from users who wanted to have hardware acceleration? So either stick with manjaro and try hacky inelegant solutions or just switch to a distro that supports hardware acceleration with its default packaged mesa.

It doesn’t pain me that manjaro removed support for patented codecs, but that they didn’t provide an alternative to existing users who are affected by the removal. Mesa-git from AUR is not a solution. Manually compiling mesa package is not a good solution. These are okay for small minor utilities, not a relatively big and important system package like mesa.

I am myself considering moving to arch on my amd machines (since intel ones still have VAAPI for some reason supported from packages on repo) by next week unless manjaro provides an alternate mesa package with patented codecs that users manually install from repos. I can’t see any reason to continue using a distro that requires me to turn to hacky solutions for basic functionality.


I checked VAAPI:

$ vainfo
Trying display: wayland
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.2.4 for AMD Radeon RX 5700 (navi10, LLVM 14.0.6, DRM 3.48, 6.0.11-1-MANJARO)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

It shows no H264 and no H265 support.

Video decoding

I checked mpv media player and twitch video stream on Firefox, they use ffmpeg, H.264 video decoding worked fine with AMD GPU hardware acceleration, CPU total usage is lower than 10% like before, nothing difference.

Video encoding

But I tried to test video encoding benchmark using ffmpeg with VAAPI

ffmpeg -hwaccel vaapi -i <YOUR_VIDEO_FILE.mp4> -f null - -benchmark

AMD CPU total usage is higher than 60%. It seem video encoding is affected when using AMD GPU and mesa. Intel iCPU has no issue.

It means that the video itself was not high enough bitrate to tax your CPU. You do not have AMD GPU hardware acceleration for H.264. Congrats on having a good CPU though

Btw, if you want to test encode or decode, download some utility like nvtop. Enable the decode and encode charts from its config


That is awesome app, thank you!

If someone is interested in just using manjaro’s builds of mesa but with support for patented codecs, they can use this simple script


cd /tmp/
git clone
cd /tmp/mesa/
sed -i '/-D microsoft-clc=disabled \\/a \    -D video-codecs=vc1dec,h264dec,h264enc,h265dec,h265enc \\' PKGBUILD
makepkg -si
cd /tmp/
rm -Rf mesa

I have no idea what the best way to automate it would be. Would be nice if someone could advise me on that front. If this script could be automated with manjaro’s mesa updates, I would not bother switching to arch (compiling does not take much time when all the files are stored in ram).

Also, probably add all the gpg keys in the PKGBUILD before running it.