The package openh264 should be available in fedora-cisco-openh264. However, I don’t remember if that repo is enabled by default (although I guess it is). Anyway, can you check the output of cat /etc/yum.repos.d/fedora-cisco-openh264.repo ? The [fedora-cisco-openh264] section should contain enabled=1 and not enabled=0. The [fedora-cisco-openh264-debuginfo] section shall remain enabled=0.
Once this is enabled, try dnf install openh264 → if this doesn’t work, please provide the full output of both the above cat and the dnf command. Also, in this case, provide the output of uname -r.
However, be aware that ffmpeg is not in the repositories that are shipped with Fedora because (as many audio/video codec packages) it causes issues with patents and such. So this is a legal issue. Thus, if you want to have ffmpeg on your Fedora, one way to get it is to enable rpmfusion-free-updates (find more here). Be aware that rpmfusion repos are not officially supported, but it might be still the “most reliable” way to get it on Fedora natively. This way also ensures that it remains updated. Installing packages by individual rpm files is not suggested because it does not ensure updates and such. Also, the quality assurance of unknown package providers is unclear → rpmfusion folks are strongly interrelated with Fedora people, and the quality assurance is comparable.
That’s the issue. You are running a future version of Fedora that is still testing. I guess the openh264 repo is not integrated with that.
You can use openh264 on a current version of Fedora. This is F38 and F39. Obviously, F40 is not yet considered in this repo. I’m quite sure the search fails when resolving the $releasever parameter.
You are aware that you run an unstable testing system that should not be used for production use but only for testing? Your kernel is itself still in development and not yet released (rc6 = release candidate). So, both your Fedora and your kernel are testing and have to be considered highly unstable. I just want to be sure that you know what you are running.
I guess there is no Fedora repo for that, and thus no F40 build of the package. If we had one, it would be resolved and found by the enabled repo.
You might download the F39 package (so, download the rpm file) and install it manually on F40. But there is no guarantee this works, although I expect it will. If there are further dependencies not satisfied by F40, you might do the same for these dependencies.
So, if you want to try this (unsupported) approach, get the packages (and all dependencies that are asked for that cannot be satisfied by F40), and do, e.g., dnf install openh264-2.3.1-2.fc39.x86_64.rpm <otherdependency1.rpm> <otherdependency2.rpm> from the very folder these *.rpm files are containted in.
Keep in mind that these packages will not be updated.
Like you rightly observed, dnf is not picking the package. I was expecting a download url (something wget can fetch). I can handle the rest. It would be nice if cisco’s repo shows package listing (indexed).
I’m commenting since I and others could find that note interesting. I intend on doing a deep dive of Rawhide for some time and those small details are interesting to know.
I think containerizing applications could serve as a good tool to aid in some potential pain points with certain software and packages. Strong options for Web Browsers, Developer tools, Virtualization tools.
Always happy to help It might be added that at this point we no longer guess but know for sure:
I guess the */40/* folder comes with the F40 release.
However, I mentioned already above that I expect it will work with the F39 files: the nature of the packages of this repo is neither tailored to Fedora nor should it be necessary to make noteworthy changes to this type of packages for different releases as long as some required packages / technologies are available.
At a wild guess, I just compared the F38 and F39 packages of openh264: both hash to the same sha256sum. So, they are equal.
If anyone needs this in rawhide, people might make a request to either create the next repo branch of this repo already when the related future release still evolves through rawhide, or something else that ensures updates.
In the end, with this type of packages, the current release’s repo branch should always be eligible for use in rawhide as long as required rawhide packages do not become “too new” (although this might cause issues from time to time when openh264 dependencies get updated in rawhide before it occurs in the releases) → but every way that ensures updates of the packages should be preferred over manual installations of rpm files.
My argument doesn’t challenge this assumption Although I don’t think your assumption is correct: based upon our wiki, the paid licensing of Cisco is limited to the binary provided by them. This would also explain that F38 and F39 builds are equal.
Indeed, it didn’t knew this detail before as well.
The above link does not use koji (as seen above, koji cannot provide the package, it only documents it). I do not see a reason why there should be a legal difference if dnf downloads from the above source or if the users do it themselves. The content of the repo comes from GitHub - cisco/openh264: Open Source H.264 Codec → BSD 2-clause license. All good so far. The related patent(s) of this implementations are covered from Cisco downstream to the users (): Fedora can use it throughout as long as we use the binaries from Cisco. Further, given the patent restrictions we have from Red Hat to protect them as the legal entity of Fedora, I have no doubt that Red Hat would not take the responsibility for this repo to be shipped by default if it could cause such issues.
A short extract from the page that koji refers to:
Cisco has paid for a patent grant for people to use this codec. However, one of the terms of the patent grant is that Cisco must distribute the binaries.
So all binaries we have shipped in Fedora are licensed from Cisco and are ok to be used downstream. Within Fedora, we do not need to care but only ensure that no one starts to create own builds from it (which is not allowed at all)
However, thanks for raising this assumption: I just learned something new Its indeed an interesting case!