On Mon, 11 Aug 2014 20:40:28 +0200
Reimar Döffinger <reimar.doeffin...@gmx.de> wrote:
> 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.
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
as kernel32.dll's.
> 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
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
> case!
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.
> Regards,
> Reimar
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-de...@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140811225356.10314342@debian
