[FFmpeg-devel] [libav-devel] [PATCH 0/20] removal of deprecated features

[wm4]

On Fri, 7 Aug 2015 19:28:26 +0200
Dominik 'Rathann' Mierzejewski <dominik at greysector.net> wrote:

> Hello,
> 
> On Friday, 07 August 2015 at 15:36, wm4 wrote:
> > On Thu, 6 Aug 2015 23:26:05 +0200
> > Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:
> > > On 06.08.2015 00:53, wm4 wrote:
> [...]
> > > > Why do we have to suffer because Debian tries to compile ancient
> > > > releases against newer ffmpeg/libav releases? (How does that even make
> > > > sense?)
> > > 
> > > This is just your prejudice that doesn't have much to do with reality.
> > 
> > I've had very much experience with distro reality. They tend to make
> > everyone's life harder (including their own) by demanding that EVERY
> > project uses the same libav* build.
> 
> Actually, speaking with my distro hat on, that's more or less the idea,
> though I wouldn't say we (Fedora/RPMFusion) are demanding anything.
> We do want to ship a single ffmpeg build per distro release and have
> each depending project link against it. If that means
> back/forward-porting code to adapt the other projects to API changes
> then that's the package maintainer's job.

That's a commendable goal, but also somewhat counterproductive. If the
devs of a project say that the software can't run with a newer or older
ffmpeg version, it probably has its reasons. I think it's not
unreasonable to ship a software with the dependencies recommended by
its developers.

But the main effect is that the distro's entire multimedia
infrastructure is held back because some relatively unimportant
programs still weren't ported to newer ffmpeg.

And somehow maintainers seem to blame the API improvement progress in
ffmpeg/Libav (especially Libav), instead of the maintainers of these
programs.

(But duplicating Python or Qt is apparently OK.)

> > Well, if you want to do this, you're free to do so. But it's not our
> > problem. Feel free to put as much effort into it as you like.
> 
> Indeed. Though we may ask politely that FFmpeg project supports a given
> ffmpeg release for the ~13 months of a given Fedora release lifecycle.

If someone takes it on... until recently we actually had a maintainer
who managed a dozen release branches or so, but I doubt other current
FFmpeg devs are so enthusiastic about it.

> We would very much appreciate porting-to-new-API guides as that would
> make providing patches to depending project upstreams a lot easier.

Actually Libav, which did pretty much all API changes (as opposed to
additions), has migration guides:

https://wiki.libav.org/Migration/10
https://wiki.libav.org/Migration/11

Of course FFmpeg merged only the git commits, but (apparently) didn't
provide any migration guides.

I think there were also ideas to provide more examples, such as for
libavresample in order to make the lavc resampler deprecation easier.
Not sure what happened to this.

At least FFmpeg has a resampler example:

http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/resampling_audio.c

> [...]
> > > >> Better documentation would surely be helpful.
> > > > 
> > > > Many of these are non-trivial. Project authors either update their
> > > > code, or the project dies. It's simple. If you don't want this, keep an
> > > > old ffmpeg/libav package around for them. But you distro peoples want a
> > > > single libavcodec package, no matter how much this fucking tortures
> > > > everyone.
> > > 
> > > So instead of keeping a little bit of deprecated code, everyone should
> > > keep multiple copies of libavcodec?
> > > This is several orders of magnitude worse.
> > 
> > Why is it worse? Disk space is very cheap, and the libs aren't that big
> > after all. But I know, you distro folks would rather waste a lot of
> > time trying to make all projects use the same libs, instead of going
> > the easy way.
> 
> Yes, we do. Once the initial porting work is done, we can fix security
> issues and other bugs in one place, by updating one package. That's
> a big maintenance win.

Applying a single patch to 2 very similar codebases is very simple.
Uploading multiple packages automatically surely is trivial.

Keep in mind that a FFmpeg maintainer would have to do the same thing.

> However, at least in Fedora, if a project can't be ported to current library
> APIs (for example because it's dead) then we either drop it or introduce
> a compat package with an older version of the library. There is strong
> preference for the first option though.
> 
> > By the way, why the hell do I have to have two versions of Qt and 2
> > versions of Python on my Debian system? These are much heavier than
> > libav*.
> 
> You're right, but there are also much more users of Qt and Python
> and there are (I think) much more extensive API changes between Qt 4 and
> 5, and between python-2.x and 3.x. They were also designed as parallel
> installable from the beginning.

So is it ok if FFmpeg changes more radically between releases, and
use different pkg-config names on each major (incompatible) bump?

> Regards,
> Dominik (FFmpeg (co-)maintainer in RPMFusion/Fedora)