[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.
> 
>> #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: coder at c-base.org
Skype: uzadow





More information about the libav-api mailing list