Hardware acceleration for AVC/HEVC/VC-1 in Mesa (required for AMD graphics)

Since the end of 2022, hardware acceleration for h264, h265 and VC1 within mesa has been removed:

This essentially breaks any hardware acceleration for these codecs when using AMD graphics. It impacts any software relying on vaapi or vdpau to decode or encode these formats, including software such as firefox, ffmpeg, mpv and so on, when running AMD graphics hardware.

Both my HTPC and laptop are running manjaro and are negatively affected by these changes, as they are both featuring amd (onboard) graphics. No hw acceleration means higher power consumption, more heat, louder fans and likely even stuttering videos and sluggish performance.

Please rethink your decision to drop hw acceleration for these codecs on AMD graphics.

P.S. Both Arch and EndeavourOS repos still support hw acceleration for these codecs in mesa.

1 Like

It isn’t a real issue anymore. Please see:


1 Like

Yeah, except things like YT should use something like VP9, which is unaffected.
Ex (I disabled vulkan, raw draw, ‘dangerous’ webgpu on purpose) :


If you want the proprietary codecs then you can use a different repo/package.


…it seems this has been asked and answered before …

X11 session not working - after driver update - #4 by banjo


Not everything is YouTube and I personally also prefer free codecs over proprietary/non-free ones, but I can only enforce that when I am creating such content and not when I am consuming it. Then, I have to take what is given: Twitch serves AVC, blurays come in VC1, AVC or HEVC variants and even my smartphone and action camera record in AVC.

All of it is no longer accelerated - at least for me and others suffering the same fate.

I have seen nonfree.eu - but who maintains that? It just seems like a random sketchy repo… That can’t be a good solution to a regression.

1 Like

When you open Mesa-freeworld, at the bottom-right you see the contributors.

And no, it is just mesa as it was before with codecs included.


A CI-bot pulls the sources upstream and build it for Manjaro.

The initial initiative is a shared Manjaro Community effort


1 Like

You could always grab the PKGBUILD (s), add the flags and build it yourself.

1 Like

I am just finding this and have installed the nonfree drivers. I tested VAAPI’s performance by playing some local 720p HEVC files with and without hardware decoding. MPV has a “stats” feature, which appears when Shift+I is pressed. The frame timing is around 600 µs with --hwdec=no, and around 800 µs with --hwdec=vaapi. My laptop has an AMD Ryzen 5500U and only integrated graphics. Why does hardware decoding take about 33% longer per frame?

Have you tested the overall throughput? Maybe software decoding is actually faster on your machine? hw decoding usually relies on dedicated hw on the chip to decode it quickly and maybe there is a bottleneck in there… which isn’t an issue as long as it can decode faster than the videos actual framerate for regular playback?

I tested h265 decoding using ffmpeg and h265 vaapi hw decoding is actually slower (~50s) than software decoding (41s) for a 60s long 4k 10bit clip. For this test I have limited it to a single thread. Power consumption (and SoC temps) are obviously higher during software decoding on the cpu (Ryzen 3500U).

though i think the frame timing is the presentation of a decoded frame itself… so maybe there is some unnecessary swapping of the frame between vram and ram multiple times or something like that? i dunno… just guessing, it’s not like i know what im talking about >_<

Just to see … in my tests I got the following frame timings (ryzen 2500u)



I tried it via mpv as well. vaapi outperforms software by around 2 to 2.5x. maybe something is different with newer amd APUs? or the performance flips at lower resolutions? I dunno…

4k 10bit h265:
no hwdec: ~8415
vaapi: ~4850

1080p 8bit h264:
no hwdec: ~2720
vaapi: ~1144