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

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.


Now at work, but later I will try
(this post is complete edited, former link was 404 today)

…edited the packagebuild (and this time no new checksum, no gpg-keys that ended in restore with timeshift) .
reboot successful


Timeshift is my friend, but still this is suboptimal.

Trying display: wayland
Trying display: x11
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.2.4 for AMD Radeon Graphics (rembrandt, LLVM 14.0.6, DRM 3.48, 6.0.11-1-MANJARO)
vainfo: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileAV1Profile0            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

…so, now lets test if this really works.

I was being cheeky…

But, yeah, given @milkytwix’s summary I’m with @BaronKarza on this.

I didn’t pay for Manjaro so, I have no justification to ask the maintainers to take a (however remote) legal risk just so that I can save 20 minutes or so - a month - compiling a single package.

However, if I was inclined to compile my own packages… I’d run Gentoo.

for the time being you can avoid recompilation and resort to this;

Why would you only opt to install mesa from the entire stack from arch repos? Either go all in or none. Otherwise you will soon have incompatible versions of mesa with vulkan drivers etc.

1 Like

read again, there is a disclaimer. FYI of the entire mesa-stack that you speak of, manjaro has only replaced mesa package only, rest of the stack is as is from arch. (atleast for now)

If you care to take a look at the PKGBUILD, you will see there are quite a few packages involved:

pkgname=(‘vulkan-mesa-layers’ ‘opencl-mesa’ ‘vulkan-intel’ ‘vulkan-radeon’ ‘vulkan-swrast’ ‘libva-mesa-driver’ ‘mesa-vdpau’ ‘mesa’)`

excuse my possible naivety. i’m learning here.

i find the same set of packages in both PKGBUILD (here is arch’s PKGBUILD for comparison) there are indeed 8 packages involved, but they are the same. BTW arch mesa has an additional patch, that manjaro does not :-p

of the packages in question, to-date, manjaro has only altered package “mesa”, the rest of it is still inherited as built by arch.

i know this is only relevant for now(this build), but what are the pitfalls in substituting manjaro’s package with arch’s

All the split packages in mesa and lib32-mesa are now built by Manjaro, without patent encumbered codec support. That means you need to replace all of the core and split packages if you want hardware acceleration back without messing up your system.


pacman -Qi vulkan-mesa-layers | grep Packager                               
Packager        : Philip Müller <>

This is basically no solution and less experienced people are left out in the dark!
This should’ve been communicated with the community before any changes were made, to try finding a different solution, but it didn’t happen.


When will the rest of the patent infringing stuff be removed? It seems the Intel VAAPI drivers are still there, along with x264 and x265. Fedora doesn’t ship any of that.

Removing all proprietary codec support from Manjaro would force me to switch to Arch immediately.(after using Manjaro since 2013).

My Fuji camera outputs 4K60p H264 and H265 streams at 200Mbit/s, and I’ve got RX6800XT. that’s why I’m so upset with recent change.

To make things worse, recent digital cameras, Like Canon R5 or newest Fuji X-T5 will output HEIF files for 10-bit stills.

And HEIF is a derivative of HEVC.

Also my Huawei phone outputs either H264 or H265 and newest phones output HEIF. This would render Manjaro unusable even for daily task.


There is official AMDGPU AMF that used for encoding/decoding hardware acceleration.

For Advanced Media Framework implementation, install amf-amdgpu-pro.

If I understand correctly, for the time being that change only affects hardware acceleration of these codecs via GPU, so you can still de/encode using your CPU - which might or might not work for you.
At the very least it will slightly increase the electricity bill, but on a laptop, with a weaker CPU or for 4k material it might very well make a very noticeable difference.
However, there’s another thing that makes me wonder. Fedora removed the acceleration and doesn’t actually offer the respective codecs by default, so they are indeed “free of patent encumbered codecs” - while Manjaro still does offer them (via software decoding), doesn’t it?
So either this will change as well down the line, the potential legal issues only involve hardware acceleration (in which case Intel and nVidia should be an issue as well, even though they don’t use vaapi), or this is a very inconsistent “solution”.

Fedora has a deal with Cisco to distribute OpenH264, the package must come from Cisco’s servers since they pay the royalties.

I don’t know where people get the idea that the patent issue is only hardware decoding or only Mesa. The Mesa implementation was an overlooked bit that Fedora recently disabled to remain compliant.

It is for only software codec, not hardware acceleration.

We would wait a long time to get AV1 as default video codec when all GPU support it, it’s royalty-free.