[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Reinhard Tartler]

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] ancient, I know, but the situation would not change if I used a
snapshot from september or later.

[2] mostly time consuming, and in the case of debian makes the "testing"
process (i.e. copying/moving an updated ffmpeg package to "testing")
incredibly painful.

[3] Reported only last week:

http://bugs.debian.org/510841 
http://bugs.debian.org/512466
http://bugs.debian.org/512946

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4