On 30.09.2013, at 14:04, Luca Barbato <[email protected]> wrote: > > I'm trying to make the api rewrite process more public/embracing, > currently there are plans to fix hwaccel (so it is more regular), > swscale (so you won't suffer to do simple things). Soon you'll see it =)
That sounds really good. If I understand why things are changing, I'm much more likely to think it's ok :-). Blog posts about api changes & how they make things easier would probably help a lot. >> 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. > > In Gentoo we did some of the work as well, we can pour together the > efforts and try to clean up the rest. I'm not involved in handling that bug, but I'm sure the Debian guys would appreciate the help. My two bugs are bugs.debian.org/cgi-bin/bugreport.cgi?bug=721047 and https://www.libavg.de/site/issues/376. > >> 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: > > doc/APIchanges should contain it, probably we should bake some git Tag: > to mark deprecation easily so we can have automatic system for it. > >> #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 :-). > > In theory the APIchanges document should have an entry like Nice. That's what I was looking for. >> 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. > > Why? Because updating is work (no package manager if we want to provide a doubleclick installer :-/), and we don't know of any new killer feature that would make us update. libav provides us with good, low-CPU-use and low-latency video playback - the problem is essentially solved. Again, this could very well be a matter of making changes more public, since we could very well be missing out on important new features that we don't know about. >> 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. > > Here we have a problem, some people want new and improved stuff with a > certain cadence (e.g. seasonal was deemed nice for them) while you ask > to slow down the deprecation (and all the cruft-removal involved). > > Currently we provide bugfix support for 0.8 and 9 and we are doing our > best to get 10 out with a great deal of improvements due the feedback we > received and we have some plans set for 11 (due probably next summer) > already. It's cool that you're providing bugfix support for older releases. OTOH, if the big distributions remove support for older versions (like Debian moving to 0.9), it doesn't help. Cheers, 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
