Unfortunately, the way this is implemented does not help Chromium at all, see the discussion under bug #2053868.

openSUSE is linking chromium 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.)

How exactly is the experience of chromium in Fedora better, if it links statically against an internally stripped down ffmpeg version?

At least it correctly reports that it does not support, e.g., H.264, so websites will (if correctly implemented) not attempt to send it videos in that format if they have an unencumbered format available. And installing chromium-freeworld gives you a version that supports the codecs and reports so.

That said, I would not object to moving Chromium to RPM Fusion altogether. I see little value in having the crippled version in Fedora to begin with. The situation is different for QtWebEngine where we need something to build core KDE applications against. That is quite similar to what you are trying to achieve with the Fedora ffmpeg-free, except that replacing FFmpeg is not sufficient for the reasons explained, we have to rebuild and replace the entire QtWebEngine.

(In reply to Kevin Kofler from comment #6)
> At least it correctly reports that it does not support, e.g., H.264, so
> websites will (if correctly implemented) not attempt to send it videos in
> that format if they have an unencumbered format available. And installing
> chromium-freeworld gives you a version that supports the codecs and reports
> so.

So if you get only h264 support if you install the version from rpmfusion, then I don't see a reason why not link against system ffmpeg for Fedora. Also it is strange that they hardcode h264 as they have all the functions in place to query if a codec is available on the system or not.

Most websites don't use h264 anymore. On YT you either get VP9 or AV1.

https://src.fedoraproject.org/rpms/ffmpeg/c/d0a64b9dfc5f49ceaaa9d282c83931c0c2e18d34?branch=rawhide

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?

The chromium code is quite strange. For webrtc it looks like it uses openh264 directly and ffmpeg doesn't work for RTC. Looking at webrtc standalone it seems to use ffmpeg. For videos on the web it hardcodes h264 without querying ffmpeg if it supports the codec.

That is basically what I pointed out all this time. (Now, if it reports H.264 as supported even if Chromium was built with "proprietary_codecs" disabled, that is even worse than I expected and a definite bug in Chromium.)

(but that "proprietary_codecs" flag is a compile-time option, so it will not help with a runtime-pluggable FFmpeg, even if Chromium handles it correctly)

About the hardcoded codec list(s), see, e.g.:
https://chromium.googlesource.com/chromium/src/+/2ce3e342ee589cacfae4a909852780815236a0c4/media/base/mime_util_internal.cc#292

See how everything depends on compile-time flags, runtime-plugging codecs is not supported.

Would be nice to make it an runtime option. The ffmpeg glue code provides functions for that.

FYI, RPM Fusion decided to drop the ffmpeg-support-chromium.patch:
https://pkgs.rpmfusion.org/cgit/free/ffmpeg.git/commit/?id=71696edc6a35c6a91c0b419368d2f4c6c79d1ac0

I've looked into chromium already. ffmpeg tools keep track of first_dts on their own so it should be possible to do the same in chromium.

https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/ab4f299e


However I'm a C developer and C++ is most of the time confusing for me. However I will upload the untested patch I have. Maybe someone can help ...

Created attachment 1863406 [details]
ffmpeg-fix-first-dts-tracking.patch

Help is much appreciated ...

(In reply to Kevin Kofler from comment #6)
> At least it correctly reports that it does not support, e.g., H.264, so
> websites will (if correctly implemented) not attempt to send it videos in
> that format if they have an unencumbered format available. And installing
> chromium-freeworld gives you a version that supports the codecs and reports
> so.
> 
> That said, I would not object to moving Chromium to RPM Fusion altogether. I
> see little value in having the crippled version in Fedora to begin with. The
> situation is different for QtWebEngine where we need something to build core
> KDE applications against. That is quite similar to what you are trying to
> achieve with the Fedora ffmpeg-free, except that replacing FFmpeg is not
> sufficient for the reasons explained, we have to rebuild and replace the
> entire QtWebEngine.

Hard disagree.  If we go this route we might as well not ship any browsers
at all.  Chromium is vastly more secure than Firefox if kept up to date and
should be what is recommended.

I've created a patch upstream to work with system ffmpeg:

https://chromium-review.googlesource.com/c/chromium/src/+/3525614

Than, I see you're updating Chromium. Would you consider taking a look at fixing this bug for your update?

(In reply to Neal Gompa from comment #20)
> Than, I see you're updating Chromium. Would you consider taking a look at
> fixing this bug for your update?

it is pretty hard to fix this in a short time. Maybe we should consider putting the patch from comment 15 into ffmpeg-free.

Than

I originally did have that patch, but I dropped it to remain ABI compatible with RPM Fusion's ffmpeg package.

Yes, the RPM Fusion ffmpeg maintainer refused to apply that patch, even though it was in Fedora, on the grounds that it was rejected upstream.

it is fixed in chromium-108