[libav-api] libav API stability

Ulrich von Zadow coder at c-base.org
Tue Oct 1 14:22:52 CEST 2013

On 30.09.2013, at 14:04, Luca Barbato <lu_zero at gentoo.org> 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.
>> 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.



Any technology distinguishable from magic is insufficiently advanced.

Ulrich von Zadow | +49-172-7872715
Jabber: coder at c-base.org
Skype: uzadow

More information about the libav-api mailing list