On 27.09.2013, at 16:05, Anton Khirnov <[email protected]> wrote: > > Hi, > On Fri, 27 Sep 2013 13:37:32 +0200, Romain Bouqueau > <[email protected]> wrote: >> Hi, >> >> I am a contributor on the GPAC multimedia project. We provide several >> tools, among them a player which relies on FFmpeg/libav for decoding.
libavg maintainer here. First, let me say that I appreciate the work that you're doing - libav/ffmpeg are the _only_ adequate solutions there are if you need audio/video de- or encoding. Anyway, I went on a bit of a rant about this a while back: https://www.libavg.de/blog/libavffmpeg-video-decoding/ The full list of broken packages with the libav 0.9 release is in this Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706798 That's quite a bit of work to clean up, and these are only the libraries that are distributed with debian. >> From where I stand, I have the feeling your API is evolving fast. We, at >> GPAC, have a linear (no branches) and slow cycle of development. It means >> that we have to support more and more versions of your API simultaneously. >> In the long-term, this is not sustainable. >> > > I'm sorry it causes trouble for you, but we don't do all the API changes > because > we like breaking other people's stuff. It's just that most of the original > pre-2006 APIs were designed either inadequately or not at all, so changing > them > was necessary to allow certain features/avoid horrible hacks. Most of the > original APIs have now been replaced, so the rate of changes should be getting > lower from now on. I can understand the sentiment and yes, the api has improved. However, from a downstream maintainer's point of view, a horribly designed api ceases to be a problem once the implementation is done ;-). On the other hand, a change in the api causes breakage and the need to update code that once worked. Of the > 10 libraries that libavg depends on, libav is the one that breaks the most. API changes also mean that sample code and tutorials break, if you google for docs, you need to make sure you have the correct version, etc. Anyway, given an error message (e.g. 'avcodec_decode_audio2 is deprecated'), how do I find out at which version of which library it became deprecated or was removed? In other words, I'm looking for x,y and z here: #if LIBAVxxx_VERSION_INT > AV_VERSION_INT(y, z, 0) How do I go from a list like this: http://www.libav.org/doxygen/release/0.8/deprecated.html to the #if above? I know I tried and it wasn't easy. Just an explanation on how to do this would help a lot :-). > Other than that, it depends on how many Libav versions you want to support. We > usually follow the 'deprecate -> release -> remove' pattern, so every API is > deprecated (with a replacement available) in at least one release before it is > removed. Supporting two different major versions should not be all that hard > then. With about a release per year, supporting two releases is not enough for us. We need to support at least three if not four years. In fact, our mac build is still based on a 2009 ffmpeg version. Again, let me say thanks for the library you're providing. I know it's complicated and hard work. Regards, Uli -- Any technology distinguishable from magic is insufficiently advanced. Ulrich von Zadow | +49-172-7872715 Jabber: [email protected] Skype: uzadow _______________________________________________ libav-api mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-api
