This relates to methods getting hardware accelerated decode working in firefox, vlc and other common software without installing mesa-git from unsupported sources like AUR, or manually compiling packages.
Even if there is none currently, what are possible methods to have it in a more accessible manner to average users of manjaro, that can be adopted by community, and if possible can be requested of developers?
As of now, this is the situation with common distros in regard to supporting hardware acceleration:
Of all the distros commonly used, manjaro has worst support as of now, and it makes it a difficult recommendation to AMD users. A simple way to get a mesa build with hardware decode support with patented software is required, that supports automatic updates and is accessible to average user.
For general idea about what is being referred to, read here
The most streamlined way to accomplish this now is to switch to the AMDGPU PRO (proprietary) drivers. They don’t rely on mesa for hardware decoding of AVC, HEVC, and VC-1.
Otherwise you’ll have to mix-and-match if you want to use a vanilla Arch package and/or try different AUR PKGBUILDs of mesa, such as mesa-git.
Have you got working hardware decode/encode with AMF driver (in amd gpu pro) on firefox/chromium or other common software?
Even if one gets hardware decode capabilities with pro drivers, its not very useful if very few software can actually make use of it
I depend on the feedback and experiences of others, since I only have Intel GPU and Nvidia GPU on my computers. 
Theoretically, while the AMDGPU PRO drivers (proprietary) are inferior to the default open source AMDGPU drivers, they should be able to decode the above video formats with hardware acceleration.
EDIT: Much software supports VAAPI, VDPAU, or both. So even if AMF is not supported, the proprietary drivers should be able to leverage VAAPI or VDPAU in a media player such as VLC or mpv.
EDIT 2: Just to reiterate, I would absolutely test this out myself, but I don’t have any AMD GPUs (integrated or discrete) to experiment with.
EDIT 3: To reiterate once more, I wouldn’t consider this a true “solution”, since by all accounts the open source AMDGPU drivers should be preferred, and are superior, and are even recommended by several distros. But it’s an alternative to playing around with different packages and trying to compile mesa yourself.
Wait, since I don’t have an AMD card, does the Manjaro Hardware tool streamline this (as it does with Nvidia cards)? Or must it also be done manually by pulling in specific amdgpu-pro packages from the AUR?
Looks like in the AUR they provide an “all in one” package-base installer: amdgpu-pro-installer
You install that package, and technically you should be good to go, likely requiring a reboot.
It is possible to mix and match open source and pro drivers per application. However, I have personally failed to get AMF decoders working with any software that interact through VAAPI interface. But then again, I can presently only test on radeon 260x and the archwiki mentions fiji or newer cards, without giving a source
Well, rpmfusion is not maintained by Redhat nor IBM. There are ways to create 3rd party repositories for Arch and Manjaro … not recommended - ask your lawyer before doing so.
I am not that concerned with legal aspect. The thing with rpmfusion is that even though it is 3rd party, fedora now provides option to enable it during initial set up and later also from within gnome software. So it is as easy as enabling say flatpak or AUR in pamac.
I don’t think I will be able to maintain a repo in near future since I am considering switching to cachy os anyways on my personal machines.
So your condition is that it must be maintained by someone not in manjaro’s team, or any member of manjaro team outside his/her official capacity?
Copyright laws are complicated and the consequences of infringement can be devastating.
Manjaro as a company has from the beginning been separated from the Manjaro distribution but as more and more consumer targeting entities partner up with Manjaro GMBH - the legal concerns become more present especially for entities located in the US.
The european copyright laws is very strict and there is very little room for interpretation and this is likely a concern for entities using Manjaro through their financial transactions with Manjaro GMBH while supplying the operating system to end-users directly.
The approach Manjaro Team has taken - although not in favor of the community - is a better safe than sorry approach and while it may be undesirable in some aspects - it is an unfortunate consequence of software patents.
There isn’t really much to do if you want to play it safe - I can only respect the team for their decision.
Arch Linux on the other hand doesn’t distribute anything definite as the end-user is completely in charge.
Therefore - with an Arch system - there is ever only one responsible for any give system - a single person - which has bought the hardware and likely is covered by that - unlike the mass distribution of preinstalled systems - which represent a completely different entity - copyright wise.
So while I can understand the annoyance - the entities partnering with Manjaro GMBH has a legal concern - which Manjaro GMBH has to address and the only logical way to address it is to adhere to the copyright laws. Until some entity take the legal rounds required - which requires an excessive amount of cash - I don’t think Manjaro GMBH has a choice.
It shouldn’t have an impact on the community but ripples - you know - a butterfly in Calcutta …
Technically yes - if you have the hardware to go with it.
And while we are at it - again this is the end-user choice and has no relation to Arch or Manjaro as an operating system.
No - the end user always have a choice - the problem is redistributing - as in facilitating the usage of copyrighted software 
I hate that phrase … It is like - if you could possibly have a similar idea and implement something similar - my patent beats your brain .
As such - if you have bought the hardware you are entitled to what-ever that hardware offers.
So all patent encumbered packages are going to be removed soon?
It isn’t just Mesa that is the problem. You’re still shipping x264, x265 and OpenH264 that violate the patents. The Intel and Nvidia drivers provide the same H264/H265 functions as Mesa did.
Mesa was the last thing needed to make Fedora compliant with those patents, they already didn’t have any of that other stuff.
Please don’t give them any ideas. 
Getting rid of all of it would force a proper solution to be found. Right now they have the worst of both worlds, AMD/Nouveau users don’t have acceleration and they are still violating patents.
Fedora has a way to deal with this, RPM Fusion has all of the stuff they can’t legally provide.
Indeed, it looks as if they stopped half-way, for whatever reason.
Now, maybe there’s more going on here for Manjaro than in case of the original commit to Mesa that got everything into motion (and why is @linux-aarhus citing copyright when it’s supposed to be about patents?).
Anyway - there’s a lot of conflicting information currently (probably due to most of us being but armchair lawyers/developers/whatever-s). But as it stands now, I might switch distro eventually - at least on my laptop where this change hurts most, although this is just one factor amongst others.
And they have likely their legal in order - they cannot afford anything but.
because patent is copyright - but copyright is not patent - patent is more hardcore copyright.
A patent is a detailed description on how to achieve something which has never been done before - therefore the inventor can hold a right to the intellectual property the idea is.
You can copyright your book - but you cannot prevent others from writing similar books covering the same subject - that is the difference between patent and copyright.
When all the big players - works on open codecs - it is only a matter of time when H264 and the other patented stuff is on their way out.
As I see it removing questioned material will only fuel and ignite further development on the open codecs - so it is likely a good thing that this has started.
The process of compiling Mesa is not as lengthy as compiling a kernel - it’s just another custom packages to the bunch of packages we already have.
And may I remind you all - it was an upstream Mesa decision to disable the codecs in question. Arch has re-enabled them - likely because they only supply the bricks in your front-yard - you are supposed to but them together. Manjaro has not re-enabled them - most likely to comply with the entities doing business with Manjaro GMBH and to avoid clashing with European copyright laws.
Yet neither are in the official Fedora repository. The “hybrid” driver for Intel is there that only supports VP9 for a couple chipsets. You know, better safe than sorry.
Everyone from the team is sure quiet about the software implementations. I guess you won’t address it so you can still claim ignorance.
A change that was pushed by Red Hat developers for their purposes.
You are right of course that a patent can be considered a kind of copyright, even though the details differ.
Yes, it’s been done upstream, but it should still be noted that Fedora (through Red Hat’s policy) is following a more consistent approach: they don’t offer the patent encumbered codecs out-of-the-box in any way, afaik. The change to Mesa was allegedly done just to patch up an “oversight” to this policy.
Manjaro OTOH, by following suit, has only disabled GPU-accelerated decoding for AMD users, while still offering all the other ways to use the codecs in question, which is rather inconsistent with the given explanation, imo.
To add to previous two posters, here is one such example:
So now, that Manjaro is aware of this, this is willful infringement. 
Does anyone know how rpmfusion.org is organized? Assuming it’s legal and all, a Manjaro users repository could work, right?
If I understand correctly, RPM fusion is similar to AUR
https://rpmfusion.org
RPM Fusion provides software that the Fedora or Red hat doesn’t want to ship.