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.
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 …) > (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. -- -- Matthias Urlichs _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
