[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

Robert Swain robert.swain
Mon Jan 26 23:59:19 CET 2009


2009/1/26 Michael Niedermayer <michaelni at gmx.at>:
> On Mon, Jan 26, 2009 at 09:52:19PM +0100, Reinhard Tartler wrote:
>> M?ns Rullg?rd <mans at mansr.com> writes:
>>
>> > Given that most of the complaints are invalid, e.g. the API hasn't
>> > changed nearly as often as they say, there really isn't much we can
>> > do.  If people want to make up false claims about FFmpeg, and then
>> > complain about them, they'll keep doing that no matter what we do.
>>
>> I have been bitten by this this week. Several bugs have been reported
>> because of the recent ffmpeg update.
>>
>> The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
>> already could clear up this issue.  The rename was done to make the gcd
>> function part of the public API; it was private before. However the
>> *perception* of users is that ffmpeg has changed ABI/API. Why? Let me
>> explain it:
>>
>> In debian lenny, ffmpeg is split in different binary packages, among
>> others libavcodec51 and libavutil49 using a snapshot from february 2008
>> [1]. In experimental, I've now updated the an snapshot from last week
>> end. Because of the version bump in libavcodec, I needed to rename the
>> binary package libavcodec51 -> libavcodec52, which is standard practice
>> in debian with SONAME bumps. The rename is done to assist transitioning
>> programs linking against libavcodec51: Packages not yet recompiled
>> against the newer ffmpeg are not instantly broken, because libavcodec51
>> left on the hard disk. It is only removed if nothing else depends on it.
>>
>> Now something interesting happens: with the new ffmpeg snapshot
>> libavutil is updated as well. It features a function rename
>> (ff_gcd->av_gcd), which is according to the ffmpeg development policy
>> OK, since it is a pure private function. However this rename breaks the
>> libavcodec51 package horribly. [3]
>>
>> In the end this means that libavutil49 must not be renamed until *all*
>> applications linking against any library of ffmpeg has been recompiled.
>> We now are aware of the issue and in future, we will express this
>> through package dependencies propoery, however the core issue stands:
>> Transitions to a newer snapshot of ffmpeg are made terribly painful this
>> way. Please note that the requirement to rebuild *all* reverse depends
>> of a library like ffmpeg is really a problem [2] for distributions like
>> debian or ubuntu.
>>
>> I just tell you this story because I think it greatly contributes to the
>> *perception* that ffmpeg changes its API/ABI too often. From a
>> distribution POV, stories like these have the *same* *impact* as an
>> API/ABI change.
>
> 1. why did you not tell this to us earlier
> 2. why did you not just add ff_gcd(){return av_gcd()} !?
>
> in that sense, a patch doing 2. under #if ...VERSION < next major
> is welcome!
>
> IMHO the gcd issue is a bug on our side not the way we/i want to do things
> when its avoidable

Thank you for being humble and making this statement. (This is a
sincere statement.)

Regards,
Rob




More information about the ffmpeg-devel mailing list