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

[juxuanu]

Even Arch will get impacted should they received a legal statement to disable the affected codecs.

Based on Germany and easy to recompile. Much safer bet. rpm packages are a mess to maintain.

[OneTimeShot]

Fortunately, h264 was released in 2003, so at least the basic implementation is going to be out of patent next year. You might not get all the shiny features, but all h264 streams can at least play...

[unis_torvalds]

This is ridiculous. If such claims were viable, then patent trolls would have already tried to extort money out of a lot of distros (and projects like VLC, mpv and ffmpeg) which have been shipping these codecs for a good while now.

I might be wrong, but my understanding is that ffmpeg does not ship with official h264, rather a scratch-built reverse-engineered spec compatible implementation, similar as it does for Apple ProRes.
Either way, there's not much point in suing a small, distributed FOSS project like ffmpeg or even VLC. They're more or less "judgement proof." Red Hat, on the other hand, and by extension IBM, is a much juicier target for rent-seeking trolls.

[antonyshen]

Will this move affect flatpak user? If yes, which app will be affected?

[stormcrow]

There is so much FUD and panic going on with these news. While it's deffinitely very unfortunate, it seems many people don't realize this change only affects the h264/265 family of codecs. They forget there's also vp9 and av01 which the vast majority of Youtube videos use for example and they aren't going to be affected by this change. I've seen a reddit post with a misleading title that vaapi is going to be disabled for Fedora 37, (without highlighting that this is only going to affect h264/265) so now everyone in the comments panic and say they're going to stop recommending or even using Fedora.

Youtube does, but much of the rest of the Internet doesn't. The vast majority of media on the internet is still mp4/h.264 including much of the home grown content. Most hardware out there in the hands of people doesn't even have vp9 hardware decoding support.

[CommunityMember]

If Cisco has their license fees maxed out, wouldn't there exist a loophole of negotiating with Cisco to offload the build to Cisco, and then distribute the resulting binary? Surely I'm missing something here though, I don't feel it can be that simple.

It should be noted that Cisco only pays for H.264 using their implementation of openH264, not H.265 or VC-1. I seem to recall that the max yearly license fee for H.265 is $25M/yr, and VC1 is $8M/yr. No one has (yet?) stepped up to fund that yearly expense or to build the processes for those other codecs. Somewhere along the way someone would also need to add in a plug-in architecture to Mesa to allow it to integrate with those various 3rd party provided libraries if they exist (and not to enable the functionality if they are not installed).

The easiest answer might seem to be for the GPU manufacturers to increase their prices (or reduce profit, but you know which they would choose) to cover the decoding hardware licensee fees in future shipped products (at least for new generations of GPUs that are starting to ship and could therefore be identified as having an included license).

[Quackdoc]

Even Arch will get impacted should they received a legal statement to disable the affected codecs.

yeah but I can just use AUR ezpz

[quikee]

I seem to recall that the max yearly license fee for H.265 is $25M/yr

There is no max for h.265. $25M/yr applies only for MPEGLA, but there are 2 more patent pools and individual companies who refuse to be in a patent pool so everyone must negotiate with them independently (and prices are not even know). Companies smelled profit so they just didn't agree to the same licensing terms they did with h.264.

[Quackdoc]

This is incredibly, both annoying, but it also makes me kinda happy, since it will help push VP9 and AV1, im annoyed since I have neither on my desktop or laptop

[ms178]

Whenever someone says he gets worse gaming performance on X distro, I just refuse to believe it. It always turns out to be something wrong on his end or something that has to do with the window manager affecting the game. I tried many distros from pretty much every family (Ubuntu, Fedora, OpenSuse, Manjaro) and got virtually identical gaming performance on all of them.

And I refuse to get into an argument with people that refuse to accept facts, like benchmark numbers, admitting that their favorite distro needs much more hand-tuning to get it to acceptable performance levels (you can gain a lot by compiling your own Xanmod-Kernel even on Fedora). And yes, I have provided numbers in similar conversations because I actually tried them all and yes, Fedora lost out by a large margin, providing a terrible out-of-the-box experience for gamers (which was even worse than the other distros you quoted which were still not that great). No, it wasn't user error, I know what I am doing. One thing for sure is that the security and debug features enabled in their Kernel have a large impact next to some other configuration choices that are good for servers and stability, but not gaming performance. They are also still using conservative flags to build their packages (no x86-64-v3 packages yet). Any yes, all these things add up hence I highly discourage gamers from using Fedora (or their gaming-spinoff Nubara). CachyOS provides a far better out-of-the-box experience and is even easier to optimize, but you can get x86-64-v3 repos also on other Arch derivatives (I'd recommend Endeavour here if you want something a bit more polished) and share all the benefits and downsides from Arch in general. I accept that Arch-based distros are not the best choice for everyone, but for gamers, I'd recommend them over Fedora any time.