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

[Space Heater]

Same way by your attempt at putting a blame to a company as a whole rather to the mesa maintainer who took responsibility of his action realizing a legal oversight. Reread your previous post to see why I replied.

No it's not the same at all (which is why you are completely unable to explain your reasoning).

The company that runs Fedora is expected to communicate changes to their userbase, full stop. The mesa maintainer is a Red Hat employee who is acting on behalf of Red Hat and made this change due to Red Hat legal policies/guidance. A Red Hat QA Engineer later stumbled upon this change and then asked why it was made on a development mailing list because he was surprised by it. For you to then imply that this mailing list post was in any way a good-faith effort by Red Hat to communicate with Fedora users is delusional at best.

[marlock]

If what they did opens them to a lawsuit and they took a while to notice and fix it, it can cost RedHat a lot of money if they indeed get sued.

Widely publicizing the change might be the FOSS way but in this particular case it's also the lawsuit loss way...

I would cut them some slack for not waving the entire world "hey everyone! we infringed on this patent for a long time because we're a mess but now we stopped, ok? please don't sue us for a guaranteed buckload... anyway, if anyone wants to keep infringing, we would be glad to help devise a way forward to do so!"

[finalzone]

The company that runs Fedora is expected to communicate changes to their userbase, full stop. The mesa maintainer is a Red Hat employee who is acting on behalf of Red Hat and made this change due to Red Hat legal policies/guidance. A Red Hat QA Engineer later stumbled upon this change and then asked why it was made on a development mailing list because he was surprised by it. For you to then imply that this mailing list post was in any way a good-faith effort by Red Hat to communicate with Fedora users is delusional at best.

In that circumstance it was a legal matter that needs to get addressed right way in order to adhere to the country laws i.e USA and also to prevent the potential lawsuit from a patent trolls (GNOME vs Rotschild for example). You basically blame the wrong person/company legally bound to comply to the country rules regardless the community. Country laws trump community unless a revolution occurs which is the harsh reality you need to take account.

[Space Heater]

In that circumstance it was a legal matter that needs to get addressed right way in order to adhere to the country laws i.e USA and also to prevent the potential lawsuit from a patent trolls (GNOME vs Rotschild for example). You basically blame the wrong person/company legally bound to comply to the country rules regardless the community. Country laws trump community unless a revolution occurs which is the harsh reality you need to take account.

I'm sorry you are having difficulty comprehending such a basic issue. Red Hat can both comply with the relevant legal issues *and* communicate to the Fedora community about the change. They chose not to inform the community.

[finalzone]

I'm sorry you are having difficulty comprehending such a basic issue. Red Hat can both comply with the relevant legal issues *and* communicate to the Fedora community about the change. They chose not to inform the community.

Nothing to feel sorry, the issue was the timing that is all. The problem in the discussion is , once again, you tried to put blame on Red Hat as a whole instead of Dave, mesa maintainer, given the fact it was one of Red Hat co-workers raising the question. The ruling about software patents was already in place long time ago to prevent potential lawsuits from patent trolls but sadly misinterpreted by some developers and users. So lets stop playing the blame game and focus on a solution instead.

[Space Heater]

The problem in the discussion is , once again, you tried to put blame on Red Hat as a whole instead of Dave, mesa maintainer, given the fact it was one of Red Hat co-workers raising the question.

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.

[OmniNegro]

Okay. Legal stuff is nauseating.

Can anyone tell me of a codec as good as x.265 that is free to use by everyone?

I was under the impression that H.265 was the commercial version, and x.265 was free to all.

So what format should I transcode everything I own into for future use? Thanks in advance.

[fuzz]

Okay. Legal stuff is nauseating.

Can anyone tell me of a codec as good as x.265 that is free to use by everyone?

I was under the impression that H.265 was the commercial version, and x.265 was free to all.

So what format should I transcode everything I own into for future use? Thanks in advance.

AV1??

[Quackdoc]

Okay. Legal stuff is nauseating.

Can anyone tell me of a codec as good as x.265 that is free to use by everyone?

I was under the impression that H.265 was the commercial version, and x.265 was free to all.

So what format should I transcode everything I own into for future use? Thanks in advance.

x265 is an encoder that is free to use, but that doesn't mean the resulting files are free to use. H265 is the specification that the resulting file needs to follow, which is where the licensing issues come in

we have VP9 and VP8 and AV1, VP8 would sit below h264 in quality:compression, VP9 above it about equal to hevc on a tier list, and AV1 far above it. though x264 still holds the best in terms of quality ceilings for encoders. if you want a good HEVC(h265) competition VP9. VP9 can achieve slightly lower compression:quality ratio at the trade off that it has much higher swdec performance.

or you could just use AV1 which has pretty good swdec but very good quality:compression ratio, the quality ceiling of aomenc and svtav1 are a little low, and rav1e is still very much on the slow side though. (they are all fairly slow)

for regular transcoding, I would reccomend using av1an + aomenc. you can use svtav1 but the quality and compression won't be good as aomenc, but it has a lot better native threading so you don't really need to use a chunking encoder program like av1an. svtav1 can still compete with hevc though.

[OmniNegro]

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.