Best way to get h264 accelerated again?

pls, don’t enter on opinion. get only targetted to the solution.

sorry, an emotional response


Using a AMD GPU - radeon - r600 …

After several tests with both manually editing the PKGBUILD script from AUR even using the @linux-aarhus repo.
I am still unable to activate the VAAPI / VDPAU in the Manjaro system.

Despite apparently compiling and installing correctly ( both AUR mesa-git 23.yyy and the @linux-aarhus personal repo with mesa 22.3.1-1.5) the system still does not work as expected.

In both repos FireFox does not even start ( even calling via terminal it does not open any window …)
with the @linux-aarhus repo version “vdpauinfo” makes a core dump …

In both repos Chromium still does not work as expected …

Even with the AUR “amf-amdgpu-pro” noone of the above makes any difference …

Any HTML5 video stream is not working properly …
Any more ideas how to solve this ?

It’s impossible, for hardware acceleration you need at least Radeon HD 7000…

1 Like

We are not on that subject - Best way to get h264 accelerated again? - #3 by linux-aarhus

sudo pacman -Syu openh264

Replying to @Tomek
My GPU is an AMD HD6850 in which the Linux kernel identifies as using the radeon driver and with the detail as r600…
And until last week everything was fine.

Today I am not able to even seen a streaming video in any browser in Manjaro.
Although still have not found what codec is being streamed as the detail in the browser player indicates HLS format…

Any idea what codec is being streamed? H264 or another one?

It is for Nvdia, you need to install libva-utils using vainfo to check video codecs.

Did you try it?

If H264 hardware decoding is disabled, then the software decoding will be performed, any video should work on the CPU.
If both decodes do not work, maybe you have another issue, it has nothing to do with this topic.

Same situation, hardware acceleration is impossible on this hardware, so that’s not the issue. You should create new topic with your problem.

Are you sure?

Radeon HD 6000 series use UVD 3 (Unified Video Decoder) that supports H264 decoding only.

In the wiki: List of AMD graphics processing units - Wikipedia

As I stated before: up until last weekend update everything were working as expected…

Sorry for being blunt…
My Manjaro system is working since 2015 with no issues whatsoever …
So the hardware acceleration is not the problem here…

In different distros everything works as expected …

Although I noticed that even with the mesa-git with h264 enabled , chromium still had the same problem of not be able to decode the video , even if the “vdpauinfo” reported as enabled …

Nonetheless I thought I could use this thread …
Although I can start a different topic though …

1 Like

I think I have proven my point …

So this is a very good example of why an unofficial repo won’t work for most users.

It is never a one size fits all - the prebuilt packages has been taken down … as they was only meant as a test - and test failed.

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

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
[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:

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.