I don’t see what’s good or relevant to this thread about that article at all. I, myself, don’t really care, but topic title could be answered in a simple sentence or two.
1 Like
Instead of making lonely decisions in the ivory tower, you would have been better off discussing this with the community at an early stage to find ways out.
Now the manjaro community is without any smart solution.
(At the foundation of the Manjaro Company it was promised that manjaro would remain a community distribution - probably a false promise).
All the polite, compliant descriptions that I read here in part, but only say: “If you do not like it so, then get out !” That is actually a shame.
3 Likes
- Youtube already uses AV1 or VP9 by default on smartphones and Desktops.
- Netflix already uses AV1 or VP9 by default.
- Apple TV+, Amazon Prime … etc, they join Alliance for Open Media and work together to support and improve AV1.
I see some new GPUs (Samsung, Intel, AMD and Nvidia) already supported AV1 hardware decode in the wiki, they will support AV1 encode.
I believe they (Many biggest companies) would change the world and make AV1 as the standard video codec in a few years.
I will convert my old videos to AV1 videos, then I can live without H.264 and H.265.
2 Likes
Banjo, the polite responses might have been modeled on your replies.
A community based distribution isn’t free of having to respect patents, but other than a company it is a bit harder to find somebody by the patent holder to sue. So from that perspective I can understand the decision.
Would earlier communication have been helpful, no question about that, but what kind of community solution would you think would have been possible? This isn’t a technical hurdle to overcome but a legal one.
- A clear separation between company and community.
- Separation of community and hardware-branded isos.
- Non-free community repo - the user is responsible.
In friendly anticipation of the next clown-face emoji.
1 Like
I don’t know the actual timeline and time sensitivity. Maybe someone was actually sued for patent infringement or was gagged or was legally blackmailed (don’t know the English term, lol) into removing the codecs.
Then, timing is important. You have to show the goodwill and remove the offensive part immediately.
And then, the “community” can discuss on how to reintegrate the missing feature. (This is currently ongoing in the linked threads.)
Better explained here: Getting Hardware accelerated decode in various software in manjaro after recent changes in Mesa - #10 by linux-aarhus
If you mostly watch videos online on websites using one of the free codecs, you might not notice this change much.
However it should be noted that those proprietary codecs are still used heavily e.g. in cameras and smartphones, so whenever you want to watch or edit one of your recordings from your cam or phone, you will notice. And it’s not exactly very convenient to re-encode them first into another (free) format.
I switched to the mesa driver from Arch Linux
Moving away from proprietary codecs might be a good thing for FOSS, but it’s a terrible thing for AMD gpu owners. My rx5700 only has encode/decode support for h264/h265 and I encode movies/clips often. So the first thing to do is to build mesa from repo and the second is to move to Arch in the future.
So to answer the thread, obviously YES, Manjaro the company affects codec support, and has and will have other effects on this community distribution.
I think this should not have happened, something is wrong in the way it is managed in my opinion, there should be a clear separation, and nothing “because of the company” should negatively affect the community distribution.
I’m not affected (yet) so I basically don’t care, but if I was, to be clear, I would not compile important system packages myself to have normal usage of my computer, I would go the easy way, and switch to Arch.
As pointed in many thread there would have been plenty of alternative solutions rather than telling people to deal with it, to use the AUR (OK come on, always the same song, you tell people AUR is not supported, but as soon as there is an issue we can read Manjaro Team members telling people to use the AUR, you’ll have to make up your mind at some point as a Team on that topic, it’s getting old now…), or compile the package themselves, or take the package from another distribution… This is really bad, a bad look for Manjaro Team, a bad experience for the user (or soon to be non Manjaro user), it is BAD.
It is the repeating issues, the lack of communication beforehand, the will of not supporting what is good for the distribution and its users (like here having basic functionalities working, with an alternative provided solution like many others do, but not only that, for instance I’m still dumbfounded by the will of not helping for MAtray when this tool is clearly a powerful one for Manjaro to spread its communication from forum and twitter easily direct to people’s desktop, and used by many people as it was once part of default installation), and so on and so on… that makes you look bad, and what drives people away from the distribution. I myself am not recommending Manjaro anymore because of all these little stuff (I don’t have the list here, but if you want I can search and compile one) that could be easily avoided, if there was some proper thought put to it beforehand, or if the team was learning from past mistakes.
The fact Manjaro is free, is driven by community of people giving time for it, doesn’t mean you are free from criticism when it looks like decisions are made by monkeys pushing random buttons and no one cares about consequences (and don’t serve me the legal thing talking point, this is not the issue here).
7 Likes
…wasn’t it more your answer ?
…proven bs…
…proven bs…
…yes, I agree, but you are proven wrong… and now ?
…ryzen 6850U no wlan with 5.15 and bad codec support OOTB.
Okay, so I was wrong — I am only human after all, and I’m not a Manjaro developer. So what do you expect me to do now? Delete my post and break the continuity of the thread? 
You can install a newer kernel from within a chroot environment.
intel graphics cards don’t use mesa - I too have an intel card and have mpv acceleration
I don’t think you are entirely correct in that statement.
I completely agree
It is not the business entity as such - it is simply knowing - which makes the difference.
If you don’t know you are breaking a copyright or patent then the copyright/patent holder will give you the chance to remedy the usage or cough up the fee to continue distribution.
SO - the maintainers - currently 19 - myself included - of which only two (Bernard and Philip) are the business entity - can be accused of willfull infringement IF they after becoming aware of the possible infringement CONTINUES to provide the infringing functionality.
There is nothing wrong with utilising such functionality as a user - but if you distribute in final form - binaries which makes infringement possible - then you are responsible and can be sued by the copyright/patent holder.
This is why Arch can continue to provide the otherwise disabled functionality - simply because as an Arch user - you are the installer - while as a Manjaro user you install a pre-configured system which - previously - enabled usage of copyrighted/patented codecs.
Other Arch based distributions like EndeavourOS which provides a pre-configured system based on Arch packages - which they become responsible for upon distribution. So if they are smart - and I know they are - they take the same step as Manjaro - distribute mesa as an overlay with the ability to hardware decode H264 and H265.
Just think of all the other stuff you require - but you build it yourself using custom build scripts mostly found in AUR.
This is only an issue because it has been removed - but that is how it is.
And therefore - moving forward - if you desperately need the now removed functionality it is on a DIY basis.
2 Likes
I think this brings it perfectly on the point. There are legal requirements that you can’t ignore as a company, and all the whining about community vs corporation does not change that.
Shouldn’t Manjaro then remove anything that might infringe on patents? Why only mesa? Why stop there?
This is the confusion of some users.
Stopping only at mesa support for hardware decoding of AVC and HEVC seems arbitrary now.
Possibly - if it is documented that it is Manjaro maintainers which are doing so willfully
Because upstream disabled the usage - and thus made it known downstream - that there is a problem.
If you continue despite knowing better then it is against better knowledge - and then it is a problem.
Please read my comment above more closely.
A good solution would be to provide two versions of mesa - the one without acceleration support would be installed by default, and the user could decide for himself which version he wants to use.
You have that - it is called mesa-git - it is a DIY - which you likely do with other functionality you require.
Please read my comment above more closely.