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

[Michael Niedermayer]

On Tue, Jun 15, 2010 at 06:34:35PM +0100, M?ns Rullg?rd wrote:
> 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.

in that case 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.

forgive me my lack of precisson
ffmpeg and ffplay should be marked to depend on libavfilter
and the cruft in them that halfway works without libavfilter should be
removed

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100615/e14bc65a/attachment.pgp>