[FFmpeg-devel] Reintroducing FFmpeg to Debian

wm4 nfxjfg at googlemail.com
Tue Aug 12 14:48:54 CEST 2014


On Mon, 11 Aug 2014 18:34:23 -0400
Theodore Ts'o <tytso at mit.edu> wrote:

> On Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote:
> > 
> > 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.
> 
> There are some best practices in API design; one of them is to
> minimize public structs as much as possible.  Instead, have blind
> pointers which are handed back by an "initialize object" function, and
> then have setter/getter functions that allow you to fetch various
> parameters or flags which modify how the object behaves.  This allows
> you to add or deprecate new flags, configuration parameters, in a
> relatively sane way.

Yes. Unfortunately, central data structures are still public, and just
making them opaque and adding accessors on top of them would lead to a
major compatibility issue, and all developers using ffmpeg would
complain big time.

In fact, the API cleanup is an ongoing process, and is what causes the
incompatibilities with each release. For example, a C library should
have a consistent naming schema. FFmpeg/Libav decided to use AV and av_
as prefixes for all symbols in the public header files. This required
fixing some symbols, which of course broke some applications.

> I have this dream/fantasy where all of the energy over developing and
> maintaining two forks was replaced by a spirit of cooperations and the
> developers working together to design a new API from scratch that
> could be guaranteed to be stable, and then applications migrated over
> to use this stable, well-designed, future-proofed API.
> 
> Call me a naive, over-optimistic dreamer, but....   :-)
> 
> (And, the yes, the new API probably should be a bit higher level.)
> 
> "Can we all just get along?" -- https://www.youtube.com/watch?v=1sONfxPCTU0
> 
>       	       	       	   	    	      - Ted

Yes, that would be nice. The FFmpeg/Libav split is mostly a
political/social issue though: it seems some (not all) members from
each side just can't deal with some (not all) members from the other
side.

How do you fix this? It seems impossible.

(Also, btw.: sometimes the low level aspect of the libraries is simply
needed. It's just that most applications would be better off with a
more high level API.)


More information about the ffmpeg-devel mailing list