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. But the damage seems already done. :-(

As for your request: The version shipped is FFmpeg 5.0. QtWebEngine 5.15.8 does not compile against FFmpeg 5 (even with the downstream Chromium patch that was applied to the Fedora package), see: https://www.mail-archive.com/rpmfusion-developers@lists.rpmfusion.org/msg26498.html

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.

The ffmpeg source package in Fedora produces binary packages suffixed with "-free", so users will be able to swap between ours and another provider as long as they only require the libraries or executables instead of package names.

The package design was done with the assistance of the RPM Fusion ffmpeg maintainer: Dominik (rathann). He's also co-maintaining the package on the Fedora side along with me and Andreas.

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.)

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.

openSUSE is linking qt5webengine with system ffmpeg which can be replaced by Packman ffmpeg just fine.

Define "just fine"… The two issues I have pointed out are not going to make the browser fail to start up or something. They are going to stealthily degrade the user experience on some websites. Some websites will be unable to play audio/video because they trust the browser when it claims to support or not support a given codec and send it the wrong or no audio/video file. Some WebRTC websites will also not work because they require H.264 encoding (OpenH264) which is only available in qt5-qtwebengine-freeworld, not in qt5-qtwebengine (and it SHOULD be the same in Chromium, I have not checked though). (Note that FFmpeg does NOT support H.264 encoding, i.e., H.264 encoding requires libx264 (not supported by Chromium) or OpenH264.)

I also do not know how OpenSUSE handles OpenH264, but I would guess their handling of it is less strict than in Fedora, where it can only be shipped through Cisco, no package is allowed to bundle it, and it is also not allowed to hard-depend on it and not even possible to link to it at compile time, as Chromium and QtWebEngine require. That makes the whole exercise of swapping FFmpeg at runtime pretty pointless because you need a freeworld build of the whole package anyway.

(To be clear: Technically, FFmpeg indirectly supports H.264 encoding through libx264 if linked against it, so the RPM Fusion build of FFmpeg supports that, but Chromium does not even try to use FFmpeg for H.264 encoding, only for decoding, I guess because it was developed against a bundled copy of FFmpeg that is not linked against libx264 and because using OpenH264 ensures that the other end can decode it even if it uses OpenH264 also for decoding, unlike Chromium. OpenH264 supports only a subset of H.264.)

With tonight's compose, FFmpeg supports H.264 through OpenH264 if it is present on the system.

This is a cool feature, but I have two major concerns with it:
1. This is a downstream patch that you are going to have to adapt for each FFmpeg release. Knowing FFmpeg upstream's stance on workarounds for patent restrictions and on dynamic codec loading, I doubt that this is ever going to be accepted upstream, is it?
2. Does this actually work in Chromium? Does Chromium not want to encode with OpenH264 directly, bypassing FFmpeg?

(In reply to Kevin Kofler from comment #9)
> This is a cool feature, but I have two major concerns with it:
> 1. This is a downstream patch that you are going to have to adapt for each
> FFmpeg release. Knowing FFmpeg upstream's stance on workarounds for patent
> restrictions and on dynamic codec loading, I doubt that this is ever going
> to be accepted upstream, is it?

It's unlikely to be accepted upstream, but it is also minimally invasive. It's straightforward to rebase and maintain.

> 2. Does this actually work in Chromium? Does Chromium not want to encode
> with OpenH264 directly, bypassing FFmpeg?

I don't know. Google Chrome itself uses FFmpeg, so I assume Chromium can be made to do so as well...

Chromium uses FFmpeg for most multimedia stuff, but IIRC, H.264 encoding uses the bundled OpenH264 directly.

(In reply to Kevin Kofler from comment #11)
> Chromium uses FFmpeg for most multimedia stuff, but IIRC, H.264 encoding
> uses the bundled OpenH264 directly.

If that's the case, we should probably tweak Chromium to dlopen OpenH264 too...

(In reply to Neal Gompa from comment #12)
> (In reply to Kevin Kofler from comment #11)
> > Chromium uses FFmpeg for most multimedia stuff, but IIRC, H.264 encoding
> > uses the bundled OpenH264 directly.
> 
> If that's the case, we should probably tweak Chromium to dlopen OpenH264
> too...

And submit that patch upstream.

FYI, we have the downstream patch now, but I strongly doubt that it will ever get accepted upstream. FFmpeg upstream actively hates any kind of workaround for patent issues and particularly dynamic codec loading. (And Libav upstream is no different on that point, so switching to that fork would not help either.)

(and Libav seems dead anyway to begin with – no wonder, I never understood the point of that fork)

Chromium has been switched to system ffmpeg now: https://src.fedoraproject.org/rpms/chromium/c/2148ca21fbc9242fb691b3f30232bdc3d239ca12?branch=rawhide

It should be possible to do this for QtWebEngine too.

QtWebEngine needs an extra patch for adapting to ffmpeg 5 too: https://github.com/archlinux/svntogit-packages/blob/packages/qt5-webengine/trunk/qt5-webengine-ffmpeg5.patch

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

The patch from Arch uses av_stream_get_first_dts(), so we have to patch ffmpeg itself before patching qtwebengine. 

I have made a pull request here: https://src.fedoraproject.org/rpms/ffmpeg/pull-request/17. But according to Bug 2053867, this patch for ffmpeg will break ABI compatibility. Should I close this pull request? I did this because I'm trying to compile qtwebengine on riscv64, and the bundled ffmpeg4 needs some patch to run on riscv64. Personally, I don't want to patch the bundled version of ffmpeg. FFmpeg upstream have support for riscv64 in newer version, and they are running automated test for it, so switch to system version is better in my point of view.

The patch from Arch is no good because it does not work with unpatched FFmpeg. The patch has already been rejected by the FFmpeg package maintainers.

You need to backport these patches on top of the Arch patch (which is only a backport of the upstream Chromium changes, but the patches below are also needed for the latest Chromium, so an upstream backport will not fix them):
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium-107-ffmpeg-duration.patch
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium-107-proprietary-codecs.patch
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium-112-ffmpeg-first_dts.patch

They also use this:
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium.spec#_1138
to ensure that switching to a complete FFmpeg will make the additional codecs work.

And this also brings us to the issue I have with switchable FFmpeg: Chromium/QtWebEngine hardcodes at compile time the list of supported codecs (and it does not even ask FFmpeg for it at compile time, but just has 2 hardcoded lists, one with and one without patent-encumbered ("proprietary") codecs – and last I checked, they were also considering even MP3 encumbered, years after the last patent expired). So allowing to switch to a different FFmpeg at runtime means the list of supported codecs QtWebEngine reports to web sites will be wrong in at least one situation. By default, it will underreport the supported codecs if you switch to a complete FFmpeg. With the above trick, it will instead overreport them with ffmpeg-free. Both can lead to video playback failing on some websites.

The only way to ensure that the list of reported codecs will always be correct is to use a bundled FFmpeg and to completely rebuild QtWebEngine for encumbered codec support (-freeworld version), which is exactly what we do right now.

(See comment #4.)

The H.264 issue mentioned in comment #6 is also still the case:
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium.spec#_1145
As you can see, Chromium is just unconditionally built with WebRTC H.264 support disabled. That will be the same for QtWebEngine, so a -freeworld package will still be needed. So with system FFmpeg, users will have to install 2 packages instead of 1 to get full codec support in QtWebEngine. I do not see how that is an improvement.

We now have a patch in our FFmpeg package to make it dlopen OpenH264, but WebRTC uses OpenH264 directly, so we need a patch to WebRTC for that.

There is a patch for Chromium that would need to be applied here too and tested:
https://src.fedoraproject.org/rpms/chromium/pull-request/29