[FFmpeg-devel] Reintroducing FFmpeg to Debian

wm4 nfxjfg at googlemail.com
Tue Aug 12 14:53:51 CEST 2014


On Tue, 12 Aug 2014 02:54:39 +0200
Matthias Urlichs <matthias at urlichs.de> wrote:

> Hi,
> 
> wm4:
> > 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?

Apparently this happens even if an application only uses C99 and POSIX
standard symbols.

> ABI backwards compatibility is not a goal I would want to spend any time
> on. Forward compatibility, on the other hand …

Well, I think it's a pretty common complaint from commercial software
vendors. That you can't distribute precompiled binaries reasonably.

> > 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.

That's already the case with most libav* data structures.

> Of course, it's only easy if you design your API that way from the
> beginning …
> 
> > 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.
> > 
> gstreamer-ffmpeg?

gstreamer has more problems than it solves. (Forces glib/gobject on
you, GTK-style OOP, pretty crashy, tons of low-quality plugins,
complicated API and design, ...)



More information about the ffmpeg-devel mailing list