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

[wm4]

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:
> > Well, you sure like to list a lot of projects.
> 
> No, I don't. I'd like it much more if the list was empty.
> 
> > But what you don't say
> > is that many of these are either definitely dead (mplayer2 comes to
> > mind),
> 
> One is not many. But OK, let's get rid of mplayer2 [1].

So why does mplayer2 have to die, but other projects are extremely
important to keep and thus no deprecated API should be dropped?

I didn't attempt to check how many projects really rely on deprecated
features, but...

> > or are ancient releases of software which fixed their API usage
> > later (like my own project, and probably most other reasonable active
> > projects).
> 
> Now I'm curious what your own project is.
> I thought you were involved with mpv, but that still uses the deprecated
> FF_API_AUDIOCONVERT [2].

It is mpv. Yes, there are 3 audioconvert.h include statements, but
usage of any of the symbols was removed almost 2.5 years ago. You only
need a trivial patch to fix it. (Or make the upstream project aware. I
didn't know about this, but removed the includes yesterday when I read
your post. Why didn't I ever get a bug report from you about this?)

How many more projects are there that can be trivially updated, but
you weren't aware of? I also doubt that software like vlc, kodi, or
chromium actually use deprecated API in their git development branches.
Why do you want to compile old releases against bleeding edge
libav/ffmpeg?

> Projects like blender, gst-libav or mplayer are reasonably recent in Debian
> and active upstream. But still they use deprecated APIs.
> 
> > 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.

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.

> > And then there's the category of projects that are "alive", but barely
> > care about anything unless being severely prodded. I'm not sure why we
> > should suffer forever just to accommodate these projects. They had more
> > than enough time.
> 
> It's actually the other projects that have to suffer, because FFmpeg/Libav
> breaks it's API. Time alone is not enough, there also needs to be good
> documentation about API replacements and that is currently insufficient.

This is all very tiring. We're trying to improve the APIs everyone
likes to complain so much about. But staying compatible forever is just
not feasible. It leads to accumulation of strange things, even if it's
minor changes like the PIXFMT renames.

Do you think anyone has it easier to develop a program using the libs
when confronted with tons of legacy symbols?

> > I feel like I'm repeating myself and others, but I don't remember
> > whether you acknowledged these arguments.
> 
> I'm seeing more dramatic words than good arguments in your mail.

OK, let's be polemic: I'm seeing outright lies from you. Not nearly
enough important software as you make it seem depends on deprecated
features, and even if, many of them are trivially fixable.

Of course older releases of them use deprecated features, because at the
time they were not deprecated yet, or were still within the grace
period. And I don't see why you see this as "proof".

(Note that sometimes it's preferable to use deprecated features,
because distros are on ancient libav* versions to keep unmaintained
software depending on it going. This also very much sucks for the
project authors, btw.)

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

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

> Best regards,
> Andreas
> 
> 
> 1: https://bugs.debian.org/794817
> 2: https://github.com/mpv-player/mpv/blob/master/audio/filter/af_lavcac3enc.c#L29