[FFmpeg-devel] [PATCH] restoring binary compatibility with ffmpeg 0.5

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Tue, Jun 15, 2010 at 03:15:56PM +0200, Diego Biurrun wrote:
>> On Sun, Jun 13, 2010 at 02:51:23AM +0200, Michael Niedermayer wrote:
>> > On Fri, Jun 11, 2010 at 06:25:08PM +0200, Diego Biurrun wrote:
>> > > On Thu, Jun 10, 2010 at 08:19:52PM +0200, Michael Niedermayer wrote:
>> > > > On Thu, Jun 10, 2010 at 05:46:23PM +0200, Diego Biurrun wrote:
>> > > > > On Sun, Jun 06, 2010 at 05:03:40PM +0200, Reinhard Tartler wrote:
>> > > > > > [...]
>> > > > > 
>> > > > > tl;dr
>> > > > > 
>> > > > > Anyway, I suggest we use the opportunity to break compatibility and
>> > > > > change APIs.  There are a lot of ifdefs that long for being removed.
>> > > > 
>> > > > The problem is not so much the "now case", a single soname bump isnt
>> > > > the big issue.
>> > > > The big issue is that we would need to bump soname everytime we move a
>> > > > symbol and thats not that rare ...
>> > > 
>> > > What about breaking compatibility now anyway?
>> > 
>> > just because we can?
>> 
>> No, because it would remove a lot of clutter and fix a few bugs in the
>> process, for example:
>> 
>> http://roundup.ffmpeg.org/issue1715
>
> If you fix 1715 and it requires bumping ABI (which almost certainly it would)
> then iam ok with bumping ABI (with a patch for review first)
>
> But note the code that would fix 1715 is not in place, simply bumping the
> ABI isnt going to fix it
> you would have to get rid of 
> grep MAX_STREAMS libav*/*.h
> first
> (it can stay in the tools ff*.c for now it also can stay in cases
>  where its not part of the public ABI though some of that we might
>  want to fix too and some we might just want to handle by bumping
>  the constant up. Its the public ABI from where it must be removed)
>
>> 
>> We want to switch over to new APIs every once in a while.
>
> do we?

If improved ones are devised, yes.

>> After all the point of putting them under version ifdefs is to
>> enable them eventually.
>
> new APIs are enabled in general old are under #if
>
> besides if we do bump ABI i think --disable-avfilter should be droped too

--disable-avfilter should stay.  It is perfectly normal to build only,
say, libavcodec.

-- 
M?ns Rullg?rd
mans at mansr.com