Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 11 Aug 2014 20:40:28 +0200
Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
> Apologies for not being able to resist answering even if it is getting
> 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.
Build something on a newer glibc system, and try to run the binary on
an older system. It most likely won't work - even if it could in
theory. (At least it was this way some years ago. Probably still is.)
So glibc might achieve some ABI backwards-compatibility, but the truth
is that they have many many issues, and the symbol versioning merely
paints them over. They can only dream of ABI compatibility as solid
> 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
To be fair, FFmpeg does its own "manual" symbol versioning by appending
increasing numbers to function names. But the real problem are not
these functions, but public structs. Imagine a new API user fighting to
guess which fields in AVCodecContext must be set, or which must not be
set. Seasoned FFmpeg developers probably don't know the horror.
> 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.
Even more importantly, libext2fs has a very specific use case. Not only
is there only ext2fs "vendor", it's also a pretty simple problem. IF
you really want to make a fair comparison, you'd have to compare FFmpeg
with a filesystem abstraction library that allows low-level accesses.
I think the largest issue with FFmpeg is actually that it's so
low-level. Users usually have to connect the individual libraries
themselves, and that is very error prone. Hell, even the official
FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem
to be broken to hell.
I think there should be a higher-level FFmpeg library that takes care
of these things.
> 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
I have the feeling glibc would have it easier if they wouldn't expose so
many internals. If you compile a program written against standard C and
POSIX, it will reference the strangest glibc symbols.
> ffmpeg-devel mailing list