I'm also looking into bringing ffmpeg into EPEL 9, though I may need help from @tdawson on that front.

Potential packages to submit: https://admin.rpmfusion.org/pkgdb/packages/k%2A/

ffmpeg-libs with stripped-down H.264 and H.265 adds more problems than it solves.

first I'd like see the performance of electron , if we can package nodejs based on electron and nwjs

ffmpeg-libs with stripped-down H.264 and H.265 adds more problems than it solves.

I guess that's a matter of opinion ;-)

One thing that was brought up in the SIG meeting that didn't get answered is the naming of the "in Fedora" packages. Would they also be named <package>-free ?

The problem is that we are then taking away the choice of the end user.
If I want/need the kdenlive from rpmfusion, because I want (or need) to use the codecs in it, how am I going to get it?
Or will kdenlive know what codecs it has available at runtime?

kdenlive depends on ffmpeg-free... user installs ffmpeg-nonfree (which replaces the ffmpeg-free and maintains API/ABI compatibility) and that is it. Nothing else to change :-)

That is how I would envision the situation, of course. The ffmpeg-nonfree should be provided by someone

Packages should either depend on the library dep that's autogenerated, or if it uses the CLI utilities, it should use file dependencies. That allows swapping implementations easily enough.

I guess that's a matter of opinion ;-)

Users will install such ffmpeg for Firefox and get very angry because of its uselessness.

Or will kdenlive know what codecs it has available at runtime?

I don't think so. ffmpeg has monolithic design. It must be rebuild if you want to enable or disable some codecs.

That is how I would envision the situation, of course. The ffmpeg-nonfree should be provided by someone

RPM Fusion already has ffmpeg and ffmpeg-libs.

I guess that's a matter of opinion ;-)

Users will install such ffmpeg for Firefox and get very angry because of its uselessness.

Or will kdenlive know what codecs it has available at runtime?

I don't think so. ffmpeg has monolithic design. It must be rebuild if you want to enable or disable some codecs.

There are other ways to make that work. I've seen it done and I'm exploring them for our ffmpeg package.

Applications have to probe libavcodec for supported codecs and deal with whatever it returns back.

kdenlive depends on ffmpeg-free... user installs ffmpeg-nonfree (which replaces the ffmpeg-free and maintains API/ABI compatibility) and that is it. Nothing else to change :-)

And if the user tries to edit/save the video in H.264 format, I think kdenlive will crash instantly, just like Telegram Desktop.

There are other ways to make that work. I've seen it done and I'm exploring them for our ffmpeg package.

OpenSUSE's version of ffmpeg is so useless that 99.99% of openSUSE users add the pacman repository right after installation.

We are talking about free (FLOSS) codecs (not as in fee, at least in freeworld countries).
There is no nonfree counterpart. just normal (full featured) one.

The concern raised by @tdawson is serious. One cannot assume runtime detection will work with any cases (either from libraries or binaries) and breaking users (or developers) assumption will have evil counterpart.
I do not consent to use my time to deal with that kind of issue. (either directly or indirectly).

Having two competing packages maintained independently (here ffmpeg) is exactly what we tried to prevent with pre-rpmfusion area.

As a project coordinator I don't want a disabled ffmpeg build to (even remotely) discredit the work done in rpmfusion because users installed the wrong ffmpeg version.

So we may take countermeasure not to interfere with ffmpeg-free in any way...

The concern raised by @tdawson is serious. One cannot assume runtime detection will work with any cases (either from libraries or binaries) and breaking users (or developers) assumption will have evil counterpart.

For KDE software, we'd treat the lack of ability to do that as a bug and work with upstream developers to resolve it. I know that this already works in openSUSE with their setup, so I don't think we'll have issues on that front.

kdenlive depends on ffmpeg-free... user installs ffmpeg-nonfree (which replaces the ffmpeg-free and maintains API/ABI compatibility) and that is it. Nothing else to change :-)

And if the user tries to edit/save the video in H.264 format, I think kdenlive will crash instantly, just like Telegram Desktop.

There are other ways to make that work. I've seen it done and I'm exploring them for our ffmpeg package.

OpenSUSE's version of ffmpeg is so useless that 99.99% of openSUSE users add the pacman repository right after installation.

I'm also working with the openSUSE folks to extend their implementation based on the work I'm doing here. The work I'm doing here is based on their stuff and I'm pushing it further than what they've done in the past.

user installs ffmpeg-nonfree (which replaces the ffmpeg-free and maintains API/ABI compatibility) and that is it. Nothing else to change :-)

Not so easy. The same lib.so. will provide the different subset of available codecs. Most applications will instantly crash due to a missing codec if they don't check for it at runtime.

for KDE software
This is not a KDE problem ?! may devs just assume a version for a given feature. And if you don't have for any reason, you will have the pieces. You probably never even looked many multimedia codec application to assume that.

Now I leaving this as I don't want abuse anyone with the false assumption that a sane discussion can be held on this topic when a package review that critical as ffmpeg in the multimedia world was reviewed in Fedora is less that a week ( see https://bugzilla.redhat.com/show_bug.cgi?id=2051008 ) without full explanation and seeking consent.
This fake review is the shame of the community.
I don't want to participate in this masquerade.

OMG. Stripped ffmpeg was approved as ffmpeg and not ffmpeg-free. So bad.

I think RPM Fusion's version should use Epoch 99 now.

OMG. Stripped ffmpeg was approved as ffmpeg and not ffmpeg-free. So bad.

I think RPM Fusion's version should use Epoch 99 now.

The source package is ffmpeg, all the binary packages are suffixed with -free. This is a totally valid way to do it, and we did it precisely because @kwizart wanted the packages to have a suffixed name.

The source package is ffmpeg, all the binary packages are suffixed with -free. This is a totally valid way to do it, and we did it precisely because @kwizart wanted the packages to have a suffixed name.

Have you checked ABI with abidiff against ffmpeg-free and the regular ffmpeg?

I did when I did the first build, but it's a good idea to continually check that and make sure we don't break ABI between the two. I'll try to develop some tooling to continually check against both and make sure we maintain ABI between the two.

I think RPM Fusion's ffmpeg should have something like this in its SPEC:

Provides: %{name}-free = %{?epoch:%{epoch}:}%{version}-%{release}
Obsoletes: %{name}-free < %{?epoch:%{epoch}:}%{version}-%{release}

If the user have RPM Fusion enabled, ffmpeg-free will be automatically replaced with full version as required by most of ffmpeg-capable RPM Fusion packages.

If the two specs were synchronized, yeah, we could probably do that. Right now, they're not. @rathann, @asn, and I worked on this together with the expectation we'd do that.

(That was part of the reason for the source package being named ffmpeg, actually!)

I think that drop-in replacements are the best option both for Fedora and RPM Fusion.

RPM Fusion's version will always have higher version due to Epoch usage and everything will be fine. No further changes will be required.

First one being brought in: ffmpegthumbs: https://bugzilla.redhat.com/show_bug.cgi?id=2156603

This will fix longstanding bugs we have about the thumbnails for Dolphin