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

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.

2 Likes

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

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

https://wiki.archlinux.org/title/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.

Yes, as I said the patent issues aren’t just with hardware acceleration.

Manjaro should be removing x264, x265 and even OpenH264 unless they strike a deal with Cisco. Otherwise they should return Mesa back to the way it was because they aren’t compliant anyway.

3 Likes

Today, AV1 is a piece of junk, unfortunately. I’ve tested it against x265 and vp9 and it fails miserably (using streams from my Fujifilm as a source).

Not only it is SLOW, but also the quality of all the codecs is very bad, so bad that even my radeon hardware encoder does better job at preserving details. With rav1e being the best, but still bad and without crf implementation. It seems like AV1 is a codec designed for internet streaming, low bitrate and rather low quality as well. libvpx-vp9 on the other hand is on par with x265. some clips look better with hevc, some with vp9.

That said if we remove even software decoders (like fedora does) then I will not be able to use my camera, my smartphone, and unable to export hevc at all (personally, I’m using vp9).

Also, no HEIF, no AAC. Multimedia disaster. I haven’t heard of any digital camera that will be able to output JPEG XL or AVIF.

Even some apps I use, like Telegram, rely on h264. So even if I tend to use vp9 and vorbis, dropping proprietary codecs is a no-go for me.

Personally what bothers me the most is, that so far Manjaro has always been a Distro for ease of use and a solid base where nearly no configuration or manual intervention is required (that’s also why it’s so popular).

Now with this change newbies and general users are going to notice, that videos might not play as smooth anymore or start stuttering at higher resolutions (can also happen on higher spec hardware).

Using CPU-Cycles for decoding is highly inefficient, especially if GPU’s have dedicated optimized hardware for it.

The weirdest part is that, as others already said, Arch upstream don’t have this issue (yet), how does it look with Ubuntu, Pop!_OS and other Distros where a company is behind it, do they also have this issue?

2 Likes

It’s sad that we don’t get a proper official explanation for the whole thing.
It is apparently suspected that Fedora/ Red Hat is under a gag order (from their own legal department, not by some court), to avoid any statement being used against them (what a sad concept).
Anyway I doubt that the same applies to Manjaro as they are not an US company.
So for now we are left with this very confusing and inconsistent situation.

3 Likes

I have to admit, as more and more of this comes out, I would likely be shifting to another distro if I only had an AMD GPU. :frowning_face: Luckily, I have Intel on one computer, and Nvidia on the other.

To AMD graphics users: For the meantime, what about pivoting to the proprietary AMDGPU PRO driver, instead of AMDGPU? (Since it uses its own proprietary stack, and should yield hardware acceleration, even with AVC, HEVC, and VC-1.)

https://wiki.archlinux.org/title/AMDGPU_PRO

I would test out different options myself, but alas, I don’t have an AMD GPU.

5 Likes

As I know, this is for h264 encoding, as described here — FFmpeg - ArchWiki

On my hardware I use this package for OBS h264 encoding, thats all.

The issue of software licence requirements for these video codecs has been subject of many news items on Phoronix and discussions within RedHat/Fedora community for a few years

Fedora developer created a push request in April that summarises the dilemma for distribution packagers and developers

meson: add a video codec support option (!15258) · Merge requests · Mesa / mesa · GitLab
The issue is you only get on the patent radar once you can actually decode something out of the box, if it doesn’t work nobody cares what you ship in the parts.

The push request links back to an article that explains further:

TL:DR
If these codecs continue to be released in ready-to-use form, Manjaro would be liable to pay licence fees. The only exemption for a licence fee is if users build the software from source

I expect that the decision to drop the codecs from the package was made by Manjaro Team maintaining packages and Manjaro Gmbh was not consulted about paying any licence fee because they knew that would be just as controversial
(eg r/troll meme could be: manjaro misuses funds to buy proprietary software)
How much would it actually cost for Manjaro to licence these codecs for legal redistribution?
Fedora/RedHat/IBM favoured dropping the codecs instead of paying for licencing. If it was expensive enough to make them to fold out of the game Manjaro probably couldn’t afford to buy into it

The only recent evidence I can find about Arch/Manjaro being aware of this licence issue is the Arch bug report that was closed as fixed
FS#74615 : [mesa] mesa 22.2+ requires changes for HW accelaration
And the Arch-like distributions were no better at being forward looking as far as I can see. Discussion in other fora only started end of September.

Manjaro does not have a legal department or technical research department so all users are responsible for reporting any concerns about packages
In this case, nobody noticed the significance until recently
IMO scapegoating someone else for failure of due diligence by everyone is lame and irrelevant
and doubly so for anyone who needed support for devices

comments that Manjaro is not at risk under intellectual copyright due to being outside US jurisdiction
is only part of the problem.
The lawyers could use Universal Code of Commerce to claim non payment on a contract, there are only a few places on the planet outside that jurisdiction that I know of and no sensible options for a Manjaro mirror (sealand is too expensive and unreliable for hosting anything)

I don’t have any idea what the terms and conditions Manjaro Gmbh directors could be required to comply with, but I know how UK company directors can be disqualified for lack of feduciary responsibilty
Directors have to at least look like responsible, law abiding citizens in public life

The best current solution is to get the package from Arch

A better solution in the near future (when all the fuss dies down) would be for someone with no obvious affiliation or history with Manjaro Team to create a third-party site with the source code and good instructions on how to build it

TL:DR2:
The only way to avoid any licencing costs and legal problems is to build it from source

I can agree that this is not consistent with the simplicity I would expect from Manjaro
But I don’t see any better way forward at the moment

And the times they are a changin’ very rapidly these days so circumstances could be very different in 2023

7 Likes

I expect that the decision to drop the codecs from the package was made by Manjaro Team maintaining packages and Manjaro Gmbh was not consulted about paying any licence fee because they knew that would be just as controversial

Well from what was said in another thread by a member of the team (@Yochanan ), it was a decision by the company, not the team.
But anyway - the elefant in the room is that Manjaro is apparently not removing support for h.264 and other “patent encumbered” codecs, they are only disabling hardware encoding through vaapi. Afaik, you can still play back h.264 videos even on your fresh Manjaro installation using the CPU for decoding, or even your hardware if e.g. on an Intel system, which doesn’t rely on vaapi apparently (edit: as has been pointed out, it does, but using an unaffected driver).

So will that go away too, eventually? Or are we left with this rather inconsistent situation?

4 Likes

If you make its hardware acceleration work in say firefox, I will give you a like

2 Likes

Intel still has VAAPI, their driver is just not in Mesa. It is intel-media-driver or libva-intel-driver.

2 Likes

Please see:

Please do not derail this thread with off-topic subjects.

No need to cite those pages without reading or trying them. I have edited them both btw, coincidentally for the very topic being discussed here.
And as to why I asked it, is simply because you can’t make AMF encoder/decoder work with firefox or chrome, or at least I have never found a way to make them to. If you have made them work, please separate the thread and create a tutorial, as it would be really helpful to many users struggling with hardware acceleration after your change in mesa. That would be an actual legitimate solution as opposed to just install mesa-git or compile it yourself. Extra points if vulkan and openGL drivers still used are mesa’s

I will repeat it again. Manjaro removed hardware acceleration support from mesa because it was trendy to do so now. There is no concern for actually mitigating litigations or user convenience, since many other packages that infringe on patents still exist in repos and preinstalled by default. If they can include intal-vaapi drivers, they can include mesa build with hardware acceleration for patented codecs supported.
As of now, this is the situation with common distros in regard to supporting hardware acceleration:

  1. Ubuntu: Not by default but possible with ubuntu-restricted-extras and few other packages all in repos and easily done with gui or cli
  2. Fedora: Not by default but easily possible by installing mesa-freeworld from rpmfusion repo. All steps possible within gui
  3. Arch and other arch based distros : Not even an issue
  4. Manjaro: Good luck dudes. Here is mesa-git that is from AUR totally unsupported or get some pro feeling by manually compiling some packages.

Of all the distros commonly used, manjaro has worst support as of now. I don’t think I can recommend it with a straight face to any laptop user or even desktop user, not at least royalty free codecs have replaced most content
Also, those saying that one could just use cpu for it, forgive me, but your advice s*cks. There is already hardware to do it. There are alternative distros that allow the hardware to be used with relative ease. If there was no alternative distro or no other way than currently is in manjaro, your advice would be a necessary compromise

8 Likes

This links for VAAPI, not for AMF, please do not try to confuse community. And this is not off-topic: you ripped off VAAPI for some codecs on AMDGPU and we discussing exactly about that to find the solution.

I merely replied to this comment. Idk why you are all getting behind me.

1 Like