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.
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.
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 >_<