Fedora Linux Disabling Mesa's H.264 / H.265 / VC1 VA-API Support Over Legal Concerns

[Quackdoc]

Thanks for the answers. AV1 does sound like the way I will go. Anyone know if there are any hardware accelerated encoders for AV1? I have NVEnc for x265 encodes, and it is literally hundreds of times faster than CPU encodes. But at current I only hear Nvidia claiming they will have hardware encode on the 4000 line of cards. And with Linux as it is, I really want to switch over to an AMD GPU. But AMD does not have any intention to support hardware encoding for AV! that I have found. (Decoding is basically going to be accelerated on everything.)

But I intend to transcode a great many things, but only one time. Then whatever format I have them in is what I intend to leave them in for as long as I live.

currently intel dgpus have hwenc for av1, the new AMD gpus and the new Nvidia gpus should have av1 encoding I think

[tokyovigilante]

sudo dnf copr enable xxmitsu/mesa-git
sudo dnf upgrade --refresh

Will get you a nightly build with codecs enabled.

https://download.copr.fedorainfracloud.org/results/xxmitsu/mesa-git/fedora-rawhide-x86_64/04882790-mesa/mesa.spec

[finalzone]

Dave is a Red hat employee acting on guidance from Red Hat's legal team. If their internal communication is so bad that no one else knew but Dave, and a QA Engineer had to ask what what was going on, then this does not put Red Hat in a better light regarding their management of Fedora.

You basically ask Red Hat to publicly violate a direct legal orders on the subject of US software patent laws. Dave's action had to occur to avoid legal liabilities that could be exploited by a patent troll. In summary, Red Hat is not legally allowed to put a public announcement related to the removal of patented software. Even OpenSUSE had to follow the suit for the same reason as nobody want to get sued. Read the Fedora mission statement showing how the matter is much more complex.

[Space Heater]

You basically ask Red Hat to publicly violate a direct legal orders on the subject of US software patent laws. .

So first you claim that Red Hat did an adequate job of informing the user base since the QA engineer posted on a public mailing list. Now you're telling me that if they ever admitted to making the change (such as the *public* git commit) they would be in legal trouble. You're delusional, multiple Red Hat employees have made public statements that it was done for legal reasons, so claiming that they cannot tell users that this change was made does not comport with reality.

Dave's action had to occur to avoid legal liabilities that could be exploited by a patent troll.

No one is disputing that this is the reason it was done, it's bizarre that you're even bringing this up.

In summary, Red Hat is not legally allowed to put a public announcement related to the removal of patented software.

Dave, a Red Hat employee, made a public git commit that said it was removed for legal reasons, the mailing list thread by a Red Hat employee is public. You have given zero proof to defend this statement and unsurprisingly there are plenty of counter examples. Nice try bud.

Even OpenSUSE had to follow the suit for the same reason as nobody want to get sued. Read the Fedora mission statement showing how the matter is much more complex

Nowhere in the Fedora mission statement does it say that they cannot even *inform* Fedora users that they made a change regardless of why it was done. As shown above they regularly make public statements about changes due to legal advice, just not in a place that informs a significant amount of their user base (until Michael writes an article on it).

[Luke]

Essentially this becomes an interoperability issue. The software patent mess does not encumber the paid software world of Windows and Mac, with the result that files created in such machines must be playable on Linux machines for a Linux desktop to be usable as a home computer. Office needs may be different. Efforts in the past to boycott codecs such as mp3 ended in failure due to interoperability. When I tried in 2004 to publish pirate radio audio reports as .ogg files, windows users were unable to play them. Audacity and liblame took care of this problem the usual way: audacity did not include the codecs, and liblame was hosted outside the reach of the US software patent trolls. Finally the mp3 patent expired, with the trolls unable to do anything about liblame or ffmpeg.

I can get away with refusing to publish anything in h265 because I don't have the bandwidth for 4K anyway and that codec isn't normally for smaller formats. I use ffmpeg w all codecs enabled just in case I need to play or transcode file distributed in an "odd" codec.MPEG-LA would not dare sue end user who are NOT corporations for fear of causing their codecs to be stripped out of web servers, browsers, and all files previously distributed in them and still offered to be transcoded. It took nothing but rumors of lawsuits over the use of the .gif format in websites to kill the format until the patent expired. No IP holder can do shit about people refusing to consume their product.

The fact that Google has sought to bypass paid codecs for Youtube even if it meant contributing themselves to codec development is huge, as it removes the Home potential buyer of new closed/patented codecs from the market. Anything Google uses for Youtube all browsers will have to be able to play, and all future GPUs will have to be able to decode at least in phones. Care to guess what would have happened to mp3 if filesharers had all been torrenting .ogg files in 2004?

Best bet for Fedora: don't ship the codecs but split the package so someone else can. Only the patent-busting codecs themselves (and in this case, the mesa subset using them) need to be hosted in "safe harbor" countries that refuse to recognize software patents. Leave the civil disobedience to those who know how to do it right and are tough targets

[finalzone]

So first you claim that Red Hat did an adequate job of informing the user base since the QA engineer posted on a public mailing list. Now you're telling me that if they ever admitted to making the change (such as the *public* git commit) they would be in legal trouble. You're delusional, multiple Red Hat employees have made public statements that it was done for legal reasons, so claiming that they cannot tell users that this change was made does not comport with reality.
[snip].

The argument is pointless as it becomes evident the comments are all about winning instead to understand the complexity of legal matters. While you want to be right, I simply stop as it becomes unworthy the time. I will leave with a simple example: will you wait for the community to fix broken faucet about to flood your home or try to limit the damage as soon as possible? Peace.

[qarium]

Thanks for the answers. AV1 does sound like the way I will go. Anyone know if there are any hardware accelerated encoders for AV1? I have NVEnc for x265 encodes, and it is literally hundreds of times faster than CPU encodes. But at current I only hear Nvidia claiming they will have hardware encode on the 4000 line of cards. And with Linux as it is, I really want to switch over to an AMD GPU. But AMD does not have any intention to support hardware encoding for AV1 that I have found. (Decoding is basically going to be accelerated on everything.)

But I intend to transcode a great many things, but only one time. Then whatever format I have them in is what I intend to leave them in for as long as I live.

on amd side RDNA2 radeon 6000 cards have aV1 decode but the 6400/6500 does not have it.
the RDNA2 on the ryzen7000 cpus do have AV1 decode.
they say RDNA3 will also have AV1 encode... but maybe not on all cards.

all intel ARC cards have AV1 decode and encode

as you say nvidia will soon also have support.

if you want AMD and also AV1 encode ASIC support you just need to wait to 3.november then AMD will release the RDNA3 cards.

[arQon]

Juries and judges in these cases already have a tenuous grasp on the issues at play, 'they continued to do it after they knew it was against the rules' is a recipe for losing the lawsuit.

Not "losing" - losing with prejudice", and being hit with massive punitive damages on top of already-huge imaginary compensatory ones. (Which MPEG-LA will argue should be X$ for every download of Fedora, times 20 or 30 for "average installs per source media"; including headless servers - the same way the RIAA claimed that someone downloading 3 songs on Napster somehow cost them $60,000+, "because reasons").

I care nothing for Fedora, and even less for IBM, but this is still a shitty position for them to be put in. Schadenfreude notwithstanding over them being the ones having their desktop sabotaged for once, this is a very unpleasant outcome for all of us.

5 months seems remarkably slow for it to happen, but IDK what Fedora's release cycle is like.

[angrypie]

sudo dnf copr enable xxmitsu/mesa-git
sudo dnf upgrade --refresh

Will get you a nightly build with codecs enabled.

https://download.copr.fedorainfraclo...mesa/mesa.spec

How long is this going go be available? Considering that Copr forbids anything that wouldn't ship by default on Fedora anyway.