[libav-api] libav API stability

Luca Barbato lu_zero at gentoo.org
Mon Sep 30 14:04:44 CEST 2013

On 27/09/13 17:22, Ulrich von Zadow wrote:
> On 27.09.2013, at 16:05, Anton Khirnov <anton at khirnov.net> wrote:
>> Hi, On Fri, 27 Sep 2013 13:37:32 +0200, Romain Bouqueau 
>> <romain.bouqueau.pro at gmail.com> 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.

> Anyway, I went on a bit of a rant about this a while back: 
> https://www.libavg.de/blog/libavffmpeg-video-decoding/

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 =)

> 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 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.

We discussed that problem at VDD, *hopefully* we'll try to make
documentation and example more accessible, but sadly we can't do all at
the same time.

> 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

2012-01-15 - lavc 53.34.0
  New audio encoding API:
  b2c75b6 Add CODEC_CAP_VARIABLE_FRAME_SIZE capability for use by audio
  5ee5fa0 Add avcodec_fill_audio_frame() as a convenience function.
  b2c75b6 Add avcodec_encode_audio2() and deprecate avcodec_encode_audio().
          Add AVCodec.encode2().

> 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.


> 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)

I'll try to give some of those more structure (since mostly had been
notes on my github wiki)

> Again, let me say thanks for the library you're providing. I know
> it's complicated and hard work.

We are trying our best but none of the people involved is paid to do
releases and it is a decently painful task.


More information about the libav-api mailing list