[FFmpeg-devel] yesterdays libavfilter merge

[Michael Niedermayer]

On Thu, May 10, 2012 at 01:27:22PM +0200, Clément Bœsch wrote:
> On Thu, May 10, 2012 at 12:47:12PM +0200, Michael Niedermayer wrote:
> > Hi
> > 
> > yesterdays merge brought in some ABI issues
> > 
> > first is libav adding a "buffersink" libavfilter/buffersink.c
> > which seems based on a old version of our buffersink
> > vs. our libavfilter/sink_buffer.c
> > 
> > second is that libav introduced our
> > avfilter_get_audio_buffer_ref_from_arrays() with different API
> > ive added that temporary under a new name to be able to finish the
> > merge quickly
> > 
> > can someone (nicolas? stefano?) maybe look into a technical solution/
> > workaround to this? maybe a configure switch so that the user can
> > decide at compile time if he needs to be compatible to the debian ABI
> > 
> 
> I don't think the configure switch will help much, user won't like this
> extra complication and will likely prefer their own workarounds.
> 
> > maybe someone could speak with libav about these issues. It really
> > seems becoming a bit ridiculous that they copy our code and slightly
> > change API while keeping the function names just to break compatibility
> > daemon404 interrested in trying ?
> > 
> 
>    <elenril> avfilter_get_audio_buffer_ref_from_arrays() is the
>    natural choice to be consistent with avfilter_get_video_buffer_ref_from_arrays()
> 
> That sounds like a good argument to me (and our problems are not them,
> even if it affects common users...).
> 
> Anyway, that function needed to be changed at some point (the planar
> argument isn't valid anymore for example), so I think we should move to
> the new function ASAP.

the new function should have been introduced under a new function
name
and libav can still change this easily, the function was just added
yesterday on the libav side while it existed for over 3 month on
ffmpegs side. And hey this is all code developed in ffmpeg, its not
as if it was or is maintained by libav.


> 
> I propose to move to the new prototype (+unexpected major bump?), and keep

if we bump major than this ends compatibility with libav completely
because they wont bump. This is not impossible but its a bigger
choice and decission that should be discussed more.

Also if you want to change the function in a ABI incompatible way,
please check if any distributions would be affected, that is do any
ship a libavfilter with the current soname that has this function ?
if nothing is affected, i guess we can just change it with a public
mentioning


> an index or public web page with "unavoidable API/ABI breakages" (where it
> could be nice to avoid too much rant about Libav, even if the cause has to
> be mentioned).

We shouldnt rant about it but we should sternly explain why issues
like this happen. First our users and library developers have a right
to know and second maybe just maybe the publicity will make people
think twice before breaking compatibility next time.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120510/a392f5c7/attachment.asc>