FFmpeg and libav

[Reinhard Tartler]

On Fri, Sep 27, 2013 at 7:25 AM, Romain Bouqueau
<romain.bouqueau.pro at gmail.com> wrote:
> Hi Reinhard,
>
>>> My advise would be to focus on Libav, as FFmpeg closely tracks
>>> "upstream", and claims to ensures API/ABI compatibility. Michael
>>> Niedermayer offered repeatedly in the past to merge every development
>>> of Libav into FFmpeg, so that should solve your struggle for good.
>>>
>>> Feel free to drop by in #libav-devel if you find some API that is hard
>>> to use or otherwise difficult. There are many nice guys that are happy
>>> listen to your concerns!
>>
>>
>> Ok, we'll try that. Thanks for the feedback.
>
>
> I took time to make tests with the latest libav this morning, both trunk and
> release/9 branch.
>
> The trunk wouldn't compile. Probably some API changes for the next release,
> that's ok.

Have the parts already produced deprecation warnings for libav9?

>
> 'release/9' is known to compile with GPAC because you and Alessio made us a
> bug report in January:
> * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693159
> * https://sourceforge.net/p/gpac/bugs/265/
> I can confirm GPAC still builds with the Debian unstable libav source:
> *
> http://ftp.de.debian.org/debian/pool/main/liba/libav/libav_9.8.orig.tar.xz,
> taken from http://packages.debian.org/source/unstable/libav
>
> The latest 'release/9' doesn't compile. So there seem to be an API breakage
> in the release/9 branch of libav.

That sounds serious, can you please file a bug with full details so
that I can reproduce the problem (such as what source to compile, how
did you configure libav, etc.)?

>
> I made the same tests with FFmpeg. Short story: every version builds.
>
> I'm not judging or comparing the quality of both alternatives. But I mention
> that libav gives us much more headache in term of API.

I'm sorry to hear that. If you provided more detail, we maybe could do
something about it.

Take care,

-- 
regards,
    Reinhard