[FFmpeg-devel] yesterdays libavfilter merge
michaelni at gmx.at
Thu May 10 14:27:14 CEST 2012
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
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
> 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
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel