Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
> 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.)
What would be the point of introducing new or updated interfaces
if you then couldn't use them?
ABI backwards compatibility is not a goal I would want to spend any time
on. Forward compatibility, on the other hand …
> 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.
That's reasonably easy – you add a function to allocate the structure for
you. That function sets a version field and/or initializes everything to
a sane default. Also, you never shrink the structure, or move fields.
Obviously, you also tell people to never ever embed the thing directly in
something else, assuming that you can't keep it opaque entirely.
Of course, it's only easy if you design your API that way from the
> 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.
-- Matthias Urlichs