[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