I have always wondered why this only ever seemed to be an issue for openSUSE and Windows. Windows covers a lot of codecs in the cost of the OS, but it does make you pay extra for some like h265 encoding.
@nMax So did a quick test in a recent Aeon install on a Dell OptiPlex 3080 Micro system… So VLC is a flatpak and intel-media-driver installed… Hardware decoding working…
I don’t think you’re reading what I’m writing, I have acknowledged that hw acceleration is working for patented codecs with intel-media-driver both in this thread and another we both partook in. Indeed:
The patented codecs being in intel-media-driver is one of the arguments that the codecs can be in the rest of the packages as well, such as ffmpeg, mplayer, mesa - which is the topic of this thread: figuring out if its possible to get some or all of the disabled codecs back into the repos (which increasingly seems possible).
That is also why I’m confused by your comment about detecting hardware, that can help with choosing what packages to install, not with re-enabling codecs in the packages in the first place (for the packages where they are disabled in official or semi-official repos).
To me it currently looks like:
Either the patented codecs being in media-driver, nvidia-drivers, debian, flatpacks and whatnot is incorrect and is a legal risk to SUSE, debian hosting sponsors and flatpak (organisation) and thus need to be removed, or which seems more likely:
That the disabled codecs can be enabled in the packages where they are not currently.
Both of these standpoints are more explained in earlier comments.
@nMax I do understand (but it’s also information for other Forum readers), but no one knows what hardware an end user is using, except the end user. So the ability to determine what works and what doesn’t with the existing packages is indeterminate.
How does one not know that what is currently enabled in the openSUSE packages works on users hardware, unless they indicate end use?
Is newer hardware more compliant with what is offered, is there some older hardware that needs x, y or z?
There are two issues;
- I think it’s probably better to ask on the Factory Mailing list as to the current status of patent encumbered codecs for going forward.
- Less dependence on adding Packman from the get go for users to really see what works/doesn’t for them, based on their hardware.
The system already selects which packages to install based on the hardware of the user: I don’t have intel-media-driver installed (cause no intel gpu) on my main system, and you likely don’t have mesa installed (if nvidia gpu) - I didn’t do that manually, it’s detected by OS. The feature you’re asking for already exists. As for the specific hardware capabilities it’s up to the packages themselves to detect what is supported, which they also already do (example “vainfo” shows media-driver can detect what your specific hardware supports).
In addition, basically every gpu younger than like 20 years or w/e supports hardware acceleration of all the codecs relevant here except h265.
The point is, the packages can’t use the codecs if they are not included at build time. In this thread we are discussing why they were removed from those packages, and if they can be reintroduced.
For some reason the patented codecs seem to be included in intel-media-driver (as an example you are familiar with) but not in ffmpeg or mesa etc. So it does not matter that both mesa and ffmpeg can detect that the hardware supports decoding for h264, the code for doing the en/de-coding is not present because they are removed from the packages by openSUSE.
The discussion might very well be relevant to take into factory mailing list, but I think its better to start here as both people in the mailing lists might read the forums, and it also allows silly mistakes like me being confused about the legal relationship between openSUSE and SUSE being ironed out before spamming any mailing list.
If somebody does a basic search, it is easy to understand why companys like Nvidia/Amd/Intel distribute licensed codecs and open source distros without income don’t. This is only an example for one codec. Packman maintainers do not pay any license fees and operate in an grey area/illegal zone.
@hui Intel is not the one distributing intel-media-driver, openSUSE/SUSE is (in our case). Nothing on that page explains why openSUSE may distribute those patented media codecs for intel hardware. If you read my previous reply to OrsoBruno, which suggested the same thing, you can see this is already under discussion:
All the information I can find indicate the idea that intel acquires licenses for others or for users of their hardware is false. I don’t think there are such deals. If there are, please link the source for that, as I asked for previously.
Please read the discussions, If we fill this with repetitions and meaningless oneuppedies or snarky comments it’s going to be unreadable by others joining in.
Most of the discussion here is about that whether license fees are necessary, with some strong arguments that they might not (anymore). Which would be nice as that would allow for a useful improvement to openSUSE!
Different sources were linked why open source distributions can‘t distribute licensed codecs but big companys which sell hard-/software can. It is up to you to do a basic search/read. Nvidia also has really good documentation how this stuff works.
If you do a search in the openSUSE news, you will find how it is possible that openSUSE has an H264 repo. openSUSE has a special construct with Cisco.
And no, this forum is the wrong place to communicate such proposals. Devs don‘t read this forum as it is a user forum. Devs use dedicated channels for developement. For them it it is a waste of time to read forums (understandable).
You are ignoring already the first sentence of my reply. Can you link the Nvidia documentation you mention? I found this, which to me indicates otherwise. If you are sitting on sources that I obviously haven’t managed to find, please share them instead! I am trying to find sources for this statement, I have linked several of the results.
This is not an official proposal, we are discussing whether or not its possible here. Of course if it ends up with something it will be posted to the factory mailing list as a suggestion - as said previously.
I’m not stating that my suspicions are right, but I need someone to actually read and reply to the arguments being made, not post statements.
This is actually useful, and a good addition to the discussion. It would indicate that if cisco is still paying things there are issues with the h264 (maybe some implementations still are encumbered?). But then the previous question remains, openSUSE has no such deal with intel, nor nvidia (would likely be in the news if the cisco one is, no?) yet opensuse can distribute that code (intel-media-driver, etc). The support of openh264 seems limited to gstreamer and maybe firefox? Is there a reason the repo is not added by default? openh264 being available does not hinder the possibility for other en/de-coders being added, neither does it answer earlier arguments, but nice find!
@nMax the Open H.264 Codec (openSUSE Tumbleweed/Leap) repository is added by default.
1 Like
I just realised, neat! Bummer only gstreamer and firefox though, or is the libopenh264 used elsewhere?
It’s covered in the license file it comes with.
Cisco openH264 License
intel-media-driver License
Both Clearly Licensed to allow for redistribution by third parties
Redistributable, only in Unmodified, Binary format, per Section 1
The openSUSE Project cannot distribute this software ourselves, from openSUSE infrastructure, due to the terms of the license, and The openSUSE Project being licensed under GPL-2.0 Terms. The Nvidia License and the GPL-2.0 are Incompatible with each other.
The AMD and Intel graphics card drivers are mostly contained within the upstream Linux Kernel, and licensed properly to comply with the GPL (if not GPL themselves, I’m not going to go look)
The Codec issue is a separate one, Cisco is ostensibly paying for whatever fees are required to ship the openH264 package (they might even be the actual owner of whatever relevant H.264 Patents exist, I don’t know)
I can only assume that what patented codecs exist within intel-media-driver are similarly the responsibility of Intel Corporation to manage the legal part of that, as they are included within Intel’s own source tree for the package, and released under their redistributable license.
H.265 Is not available in any form under a redistributable license. It can be distributed free of charge, for the first 100,000 units, per https://www.via-la.com/licensing-2/hevc/hevc-license-fees/ But considering how the linux community pitches a temper tantrum anytime anybody brings up the idea of telemetry, of any form, exactly how would “The openSUSE Project” track exactly how many times they’ve distributed this software, in order to make sure they’re in legal compliance with the Royalty Fee structure?
Look. Codecs are a problem, due to Software Patenting. I agree, and I hate the situation.
Packman and RPMFusion can get away with “skirting the legality” because
A) They’re not Actually connected to a corporate entity that is worth suing (like openSUSE is to SUSE, or Fedora is to Red Hat)
B) They’re just small potatoes in the grand scheme, and not worth somebody like Via-LA suing.
C) I believe both Packman and RPMFusion are fully hosted in countries where Software Patents are Illegal, Unenforceable, or otherwise invalid.
So No, unless something were to change, wherein SUSE no longer has any legal exposure to jurisdictions where Software Patents can be enforced, or “The openSUSE Project” is legally separated from SUSE, and only operates infrastructure and legal structures in jurisdictions where Software patents are unenforceable, this isn’t a situation that is going to change, and none of this patent encumbered software is going to be allowed into the Main software repositories.
And technically even if you are getting your codecs from Packman, but you’re in a jurisdiction where those Software Patents apply, however unlikely it is for it to happen (which is pretty damned close to zero), you are technically supposed to be giving your thirty pieces of silver to whomever holds those software patents and/or Licenses that requires Royalty fees, personally, as the end user.
7 Likes