Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 05 June 2022 at 19:15, Kevin Kofler via devel wrote: >> It is common knowledge that Fedora is/was effectively useless for >> anything remotely related to multimedia without RPM Fusion packages. > > That's entirely false. There are many multimedia-related uses which are > covered solely by the package set shipped in Fedora repositories. For > example, a DLNA server on my home LAN works just fine with minidlna and > ffmpeg-free. You can use ffmpeg-free to manipulate videos encoded with > royalty-free codecs. Most videos on YouTube are also available in either > VP9 or AV1 and with Opus audio. That is why I wrote "is/was": There is now indeed limited support for multimedia in stock Fedora, so the (outdated) expectation that nothing works at all without RPM Fusion has now become overly pessimistic. Still, it is the common expectation and everyone has learned to deal with it for years, so I do not see why changing that was worth doing at all. (And the fact that almost all YouTube videos actually work without any H.264, AAC, or EME DRM support at all just proves that it was not necessary to add support for decoding H.264 and AAC to Fedora proper nor to allow browsers to easily download the Widevine blob.) > Unless you're a lawyer, the above statement is false. Red Hat legal says > the modified FDK-AAC is free and GPL-compatible, so there's no violation > of licenses here. Red Hat Legal's interpretation is in direct contradiction to the FSF's attestation that the FDK-AAC license is not compatible with the GPL. Red Hat Legal's claim that a license can be GPL-compatible or not depending on whether the code happens to implement some patents or not sounds highly dubious to me, and that view does not seem to be shared by the FSF nor by FFmpeg upstream, and it is their license (drafted by the FSF and applied by FFmpeg upstream to their code) that we must comply with. It is particularly bizarre that Fedora is willing to put themselves at risk of a lawsuit over divergent license interpretations as a result of an effort, ironically, to ship something compliant with US law. >> All these compromises: >> * violate the core Freedom principle of Fedora, and > > How? Because the copy of OpenH264 shipped through that Cisco repository is not Free Software? (All the binaries covered by the patent license impose the non-Free restrictions of that patent license, see http://www.openh264.org/BINARY_LICENSE.txt .) Because we replaced an LGPL- licensed AAC implementation with one that Debian considers non-Free? Because we ship a linked-together mix of code that FFmpeg upstream considers non- redistributable (as a mix of GPL and GPL-incompatible code)? Because we allow browsers to download proprietary DRM blobs? Plus, the compromises also violate the Features principle because Fedora deliberately ships incomplete implementations of H.264 and AAC. >> * lead to a degraded user experience compared to just installing fully >> functional multimedia codecs under Free copyright licenses from RPM >> Fusion. > > Which Fedora cannot legally ship. But RPM Fusion can, so why not just let RPM Fusion do it? Shipping the incomplete implementations just makes it harder to use the complete ones (because the FFmpeg-native implementations of H.264 and AAC (and libx264 for H.264 encoding) are not binary-compatible with OpenH264 and FDK-AAC that Fedora is pushing), for no practical benefit whatsoever because everyone can just install the codecs from RPM Fusion. >> In some cases, concerns raised by RPM Fusion developers have been >> deliberately ignored (e.g., in the AAC case). > > It was not ignored. The case was referred to FESCo where it was > discussed and a decision was made to go ahead with the limited decoder. That is exactly my point: The concerns were ignored by FESCo. > That is also blatantly false. The idea was posted by Andreas on > rpmfusion-developers list in November 2021 and I (one of the FFmpeg > maintainers) was the only one who responded. The other maintainers made > no comments in that thread. Yet, if you see the discussions on rpmfusion-devel about FFmpeg shortly before ffmpeg-free was introduced to Rawhide, nobody there was aware of the plans, at all. There was discussion on when to move to FFmpeg 5, but apparently nobody was aware (or those that were did not share the information) that an incomplete FFmpeg 5 was about to land in Fedora (forcing RPM Fusion to ship that version independently of whether that would have been the plan anyway or not, in order to be binary-compatible to the extent possible – note that software like Chromium hardcodes supported codec lists at compile time and hence it is absolutely impossible for FFmpeg builds built with different codec sets to be binary-compatible for those applications, a concern that I had pointed out in the 2021 thread and again this year and that was just blamed on the applications without any attempt to actually fix the problem for the users). I would also like to point out that the FFmpeg bump to FFmpeg 5 in RPM Fusion happened after the upstream Fedora 36 feature freeze and hence IMHO too late. But RPM Fusion's hand was forced there. You are right that there was some discussion of the ffmpeg-free idea back in 2021, but the feedback was negative (so I would have honestly expected this horrible idea to end there, as in all previous cases over the years where a naïve maintainer had a similar idea, but ended up listening to the strong reasons not to do that) and there again, the concerns were ignored, and the plan worked on with no further public communication. The irritating impression I get is that that was deliberately done so that concerns could no longer be raised until it was too late. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
