[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Reimar Döffinger]

Hello,

Apologies for not being able to resist answering even if it is getting
off-topic.

On Sun, Aug 10, 2014 at 05:43:33PM -0400, Theodore Ts'o wrote:
> On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote:
> > 
> > High quality libraries must iterate on their API. Especially for a library
> > trying to solve such a complex problem as audio and video encoding and
> > decoding for every codec and format. It is unreasonable to expect no
> > incompatible changes. Also both ffmpeg and libav codebases have a lot of
> > legacy cruft. Libav is making a more concentrated effort at improving this,
> > and the evolving API is a side-effect of that.
> 
> I beg to differ.  My definition of a "high quality library" is one
> where careful design is taken into account when designing the
> ABI/API's in the first place, and which if absolutely necessary, uses
> ELF symbol versioning to maintain ABI compatibility.
> 
> There are plenty of "high quality libraries" (glibc, libext2fs, etc.)
> where we've been able to maintain full ABI compatibility even while
> adding new features --- including in the case of libext2fs, migrating
> from 32-bit to 64-bit block numbers.  And if you're careful in your
> design and implementation, the amount of cruft required can be kept to
> a very low minimum.

While you certainly have a point that we have a lot to learn and improve,
your comparison is not entirely fair, for reasons like

a) glibc, libext2fs are much older projects, we still have to
pay for old sins, from times where everyone was happy when
their video played at all on Linux and nobody complained about
ABI compatibility. Not to mention few of us having much experience
in software development.

b) A good number of our users are on Windows, which makes symbol
versioning a very undesirable solution. Sometimes that means alternative
solutions which are messier or more likely to break compatibility by
accident

c) For libext2fs your users won't claim a file system is ext2, when it
is actually btrfs and still expect your ext2 library to work with it!
That is very much the standard in multimedia ("everything is .avi",
"I don't care what format it is, I just want it to play", ...).
Nor do you have competing ext2 implementations adding completely
mis-designed extensions to it, with everyone expecting you to support it, that
definitely makes API design a _lot_ more challenging.

d) At least in the case of glibc that backwards-compatibility is not at
all free to its current users. _IO_stdin_used is a prime example of that,
anyone playing with methods to reduce binary size/strip symbols will stumble
over that and curse very loudly at some point.
I certainly would have preferred it to not be ABI compatible in that
case!

Regards,
Reimar