[FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()

[wm4]

On Tue, 23 Jun 2015 11:05:31 +0200
Nicolas George <george at nsup.org> wrote:

> Yes, libavspellcheck! I used it as an absurd example, but if you think
> carefully on it, it is not actually absurd.

I think you're alone with this.

libav* are for (de)muxing and decoding/encoding. That's why people are
using it. Everything else FFmpeg does extremely badly, and thus is
better done somewhere else. It all boils down to API and organization
really.

It wouldn't be much of a problem to add a separate git repo that
contains libavspellchecker. This would be truly independent. But I know
what would happen... you'd add subtitle support to libavfilter, and the
spell checker would be implemented as a filter.

We could have libavremotefileoperations too, but no, it will just end
up in libavformat.

Oh, and even if we had libavspellchecker or libavremotefileoperations,
it would have to be part of The Big Git Repo. For some reason. Even
though the sub-libs are supposed to be independent. (Totally.)

Your arguments all make sense, but the way things will actually be done
is different and usually terrible.

(Just think about it. Things such as adding video outputs through a
muxer API just because the original authors didn't know a better place
for it. Using a muxer API for video output is absurd, but if you bang
your head against ffmpeg.c enough, your brain matter becomes squished
enough that it starts making sense.)

Regarding bloat: distro versions of FFmpeg are typically extremely
bloated. It's fun to watch: merely linking a C source file containing
only a main function to Debian's build of libavformat will allocate
at least 10 MB of RAM on program start. Bloat is bad because it adds
up. And you can't escape it either. If you link to a distro build of
libavformat, your program will use more memory and will take longer to
load as it would if you'd compile it yourself.

I'm also not sure why you think maintaining essentially dead code is
hard. Hint: it is pretty hard if you actually want to make FFmpeg saner
overall. Bloat is like the concrete that keeps entangled software
entangled.