[FFmpeg-devel] Reintroducing FFmpeg to Debian
nfxjfg at googlemail.com
Tue Aug 12 17:03:55 CEST 2014
On Tue, 12 Aug 2014 16:51:40 +0200
Matthias Urlichs <matthias at urlichs.de> wrote:
> > 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.
> One could add weak aliases and/or marked-as-deprecated C macros
> instead of doing a "hard" renaming.
But this was done:
FFmpeg still has them, Libav removed them about half a year after
> To be fair, the GCC change which even allowed emitting a warning upon use
> of a macro isn't _that_ old …
> > 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.
> Kick the non-cooperating people off both projects. :-P
> (One slight problem with this solution is that the net effect is likely to
> be three forks instead of two, not one …)
Yes, or kill the project entirely, since key people would have to be
kicked off. A bit of a problem, as you see.
> > (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.)
> Most CS problems can be solved by adding yet another level of indirection –
> except for the problem of having too many levels of indirection and –
> relevant here – the associated decrease in speed.
Speed wouldn't be affected here, since the "hard work" is done in
More information about the ffmpeg-devel