stable

ffmpeg-5.0-1.fc36

FEDORA-2022-78a5cbdceb created by ngompa 2 years ago for Fedora 36

Automatic update for ffmpeg-5.0-1.fc36.

Changelog
* Fri Feb 11 2022 Andreas Schneider <asn@redhat.com> - 5.0-1
- Initial import (fedora#2051008)

How to install

Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:

sudo dnf install --refresh --advisory=FEDORA-2022-78a5cbdceb \*

This update was automatically created

2 years ago

This update's test gating status has been changed to 'waiting'.

2 years ago

This update's test gating status has been changed to 'ignored'.

2 years ago

This update has been submitted for stable by bodhi

2 years ago
User Icon kkofler commented & provided feedback 2 years ago
karma

I am not convinced that this is a useful thing to ship in Fedora. It is only going to make the work for RPM Fusion more complicated and provides no real value. The F36 package also "upgrades" the RPM Fusion version (which is FFmpeg 4.4) to FFmpeg 5 (a source- and binary-incompatible version) with crippled codec support, breaking almost all packages in RPM Fusion.

RPM Fusion has FFmpeg 5 only in Rawhide so far, not F36 (and several things do not yet build against FFmpeg 5, so they are also working on a compatibility package). There was also no discussion whatsoever about moving the RPM Fusion package to ffmpeg-freeworld. I consider it entirely unacceptable to squat the name of probably the most high-profile third-party-repository package without even talking to that repository's mailing list about it first.

User Icon ngompa commented & provided feedback 2 years ago

@kkofler The RPM Fusion ffmpeg maintainer was involved in the whole process. F36+ is already ffmpeg 5 in RPM Fusion, and the two packages will be synchronized by @rathann (who is the maintainer on the RPM Fusion side).

User Icon kkofler commented & provided feedback 2 years ago

How is this going to work with both packages having the same RPM Name? RPM Fusion packages normally cannot have the same Name as Fedora packages, for good reasons.

User Icon ngompa commented & provided feedback 2 years ago

@kkofler The binary packages are different but swappable. The ABI will be the same.

User Icon ngompa commented & provided feedback 2 years ago

To clarify, all binary packages have -free in Fedora, and RPM Fusion ones lack the suffix. You will be able to swap between them as you wish.

User Icon kkofler commented & provided feedback 2 years ago

There is no way this can work properly for Chromium and QtWebEngine because Chromium hardcodes the list of supported codecs at compile time, based on whether the use_proprietary_codecs (where by "proprietary", they really mean patent-encumbered) flag is set at compile time or not. (And this is a boolean toggle between 2 hardcoded lists, there is no attempt at determining what codecs the linked FFmpeg actually supports, neither at compile time, nor at runtime.) So if you sneakily swap the FFmpeg used at build time for another one at runtime, you end up with websites getting told a wrong list of supported codecs, leading to broken websites.

So I see building both qt5-qtwebengine and qt5-qtwebengine-freeworld with bundled FFmpeg (whereas previously, -freeworld was built with system FFmpeg from RPM Fusion) as the only way forward. (It is currently the only thing that will build anyway, because FFmpeg 5 is not supported. But even if that is fixed, using swappable FFmpeg will break things.)

User Icon kkofler commented & provided feedback 2 years ago

In addition, in order to support WebRTC with H.264, QtWebEngine (and Chromium too, I suppose) needs to link against OpenH264 at compile time. Dlopening it, as Firefox apparently does, is not supported. As I understand it, this is also not allowed in Fedora. qt5-qtwebengine-freeworld is linked against a bundled copy of OpenH264 which is ripped out of the tarball in the Fedora qt5-qtwebengine. Hence, qt5-qtwebengine-freeworld cannot go away even if we link it against system FFmpeg.

So the swappable FFmpeg just makes a mess for Chromium and QtWebEngine and does not help at all.

User Icon kkofler commented & provided feedback 2 years ago

This should really have been taken to the public rpmfusion-devel mailing list, not just discussed behind closed doors with one person, who was clearly not aware of the implications on FFmpeg's consumers.


Please login to add feedback.

Metadata
Type
newpackage
Karma
-1
Signed
Content Type
RPM
Test Gating
Settings
Unstable by Karma
-3
Stable by Karma
disabled
Stable by Time
0 days
Dates
submitted
2 years ago
in testing
2 years ago
in stable
2 years ago
BZ#2051008 Review Request: ffmpeg - A complete solution to record, convert and stream audio and video
0
0

Automated Test Results