On Tue, 12 Aug 2014 16:51:40 +0200 Matthias Urlichs <matth...@urlichs.de> wrote:
> Hi, > > wm4: > > 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: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=104e10fb426f903ba9157fdbfe30292d0e4c3d72 FFmpeg still has them, Libav removed them about half a year after adding them. > 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 libavcodec anyway. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
