On Tue, 12 Aug 2014 02:54:39 +0200 Matthias Urlichs <matth...@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, ...) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
