I understand your point @linux-aarhus , so I keep my Manjaro system as close to the Manjaro repos as possible … but right now I do not have a fully working system …
( Nonetheless I have to try something to solve my problem … )
I wrote a simple python script that installs the MESA packages from the ARCH LINUX repositories. The only mandatory caution about using it is to make sure your system is up-to-date before running it in a terminal window. It’s unattended after you enter your credentials at the sudo prompt, but no different from what would happen if you have chosen to install a meta file. Provided “as is”.
1 Like
That is indeed possible - but likely only if you are on unstable branch.
If you are using stable branch it is likely better to build it yourself.
1 Like
That’s a good point. I wish I could test it with different branches, but that’s a no-go option given my limited resources, so your warning is more than right on the money.
It would also be advisable to create a restore point in timeshift before running that script in case anything goes wrong. In fact its likely a good idea to create a restore point with any of the methods in this thread.
I followed the steps to" Install the official proprietary driver AMDGPU-PRO from AUR" and nothing changed.
System keep in free driver without accelerated
vainfo:
Trying display: wayland
Trying display: x11
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Mesa Gallium driver 22.3.1 for AMD Radeon Graphics (renoir, LLVM 14.0.6, DRM 3.49, 6.1.1-1-MANJARO)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
mpv:
[ffmpeg/video] hevc: No support for codec hevc profile 2.
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 3840x2160 yuv420p10
Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text
VA-API and AMF are different video codec API, so both are separate. VA-API was built in mesa and ffmpeg too.
mpv, firefox and many media apps use ffmpeg by default, but I read a bit that ffmpeg refused to support hardware video decoder for AMF, but using VA-API as the default API.
That is why you used vainfo to detect only VA-API video codecs, never other APIs.
For example:
check about:config in firefox → search: “ffmpeg”:
media.ffmpeg.enabled true
media.ffmpeg.vaapi.enabled true
media.rdd-ffmpeg.enabled true
media.utility-ffmpeg.enabled true
firefox → ffmpeg → VAAPI, but not AMF.
Unfortunately, you only use VA-API for mpv.
ffmpeg only supports AMF encoder but not AMF decoder. You only need the decoder to watch video streams.
There are 4 competing video codec APIs:
VA-API vs. AMF vs. VDPAU vs NVDEC.
1 Like
I also tried the AMDGPU-PRO package from AUR …
Compiled and installed correctly but no changes whatsoever …
Although chromium receives correctly the HLS stream from a site, I noticed that the network bandwidth is reduced to almos zero instead of going up.
Also I were expecting the main CPU to start processing like crazy but that is not seen …
CPU is kept below 20% ( almost as being idle ) when receiving the HLS stream …
Any more ideas ?
Better. Changing the output, from GPU (openGL-FFMPEG-VAAPI) to VA-API in SMPLAYER the CPU usage is below 25% for 2160p HDR H.265 video. But before this update it was only 5%. Same result for FIREFOX.
Thank you.
for me the repo packages are working correctly, all of them… so… I have no idea.
don’t mention amf pls , no more. It’s not a solution either over the paper.
vdpau it’s for amd too. It’s official actually.
For me youtube was giving me problems without the h264 support because the videos were starting like 30 seconds after trying it. It’ worked, yeah, but not in the best way because of the time to get start( not a problem from the cpu, I think it’s firefox config)
may be putting arch repos inside pacman.conf and putting some more config that the same but… automatically only for some packages??
Hi, I’m affected by this issue looking for help. After the upgrade I’ve lost HW acc. From the instructions here to build mesa locally from the repos Upstream mesa removal of AVC/HEVC/VC-1 hardware acceleration (AMD GPUs) - #31 by Leo
#!/bin/bash
cd /tmp/
git clone https://gitlab.manjaro.org/packages/extra/mesa.git
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
It builds and installs but when trying to play a video via mpv or vlc or trying to run vdpauinfo I get this error:
mpv: ../mesa-22.3.1/src/compiler/glsl_types.cpp:1245: static const glsl_type* glsl_type::get_array_instance(const glsl_type*, unsigned int, unsigned int): Assertion `glsl_type_users > 0' failed.
Aborted (core dumped)
Downgrading to the previous version with pacman -U /var/cache/pacman/pkg/mesa-22.2.3-1.1-x86_64.pkg.tar.zst /var/cache/pacman/pkg/mesa-vdpau-22.2.3-1-x86_64.pkg.tar.zst gives HW acc back but I also lost realtime privileges (laptop used as a DAW) - continuous xruns when playing video/audio
From lshw:
ATI Radeon HD 5650M(obile) graphics card
*-display
description: VGA compatible controller
product: Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
From cat /proc/cpuinfo
Intel Core i5 M 450 2.40GHz (Arrandale) circa 2008
model name : Intel(R) Core(TM) i5 CPU M 450 @ 2.40GHz
mhwd-kernel -li
Currently running: 5.15.79-1-rt54-MANJARO (linux515)
The following kernels are installed in your system:
* linux419
* linux515-rt
Any help to get HW acc back would be greatly appreciated --thanks
He has edited it so now it’s only a script that build it, no more repo is linked here. 
This change came from nowhere… If this legal thing is now a concern after many years, what will happen when Vulkan came out next year with h264/265 and other coding-decoding capability?
The AV1 video codec is completely license-free and will become the standard video codec in the future.
Today, Intel Arc GPU and Nvidia RX 4000 series or new GPU already supported AV1 encoding and decoding.
You can forget about H264 and H265 from year 2025.
For most existing hardware, AV1 is atrociously slow at encoding. It’s almost comical how slow it is. 
To be clear, it’s promising for the future (quality, performance, hardware decoding and encoding, “open”), but for today, and for users who want to exploit hardware decoding and encoding, they’re mainly looking at AVC and HEVC. One obvious exception being YouTube, which is mostly VP9 now.
This is why it’s crucial for AMD GPU users to continue benefiting from hardware decoding of AVC and HEVC video streams.
1 Like
I guess there are different settings for AV1 in ffmpeg.
A low setting would speed up AV1 encoding when its compression ratio is worse or like HEVC. 
I will test and compare 3 codecs for my CPU without hardware acceleration tomorrow.
You don’t have AV1 with pre NAVI (RX5000 series) Radeons… And all of our downloaded movies are encoded with x264 or x265.
I know, streaming is a thing and youtube uses AV1, but this situation it still sucks. Especially for people with older Radeons…
1 Like