[Ffmpeg-devel] Using ffmpeg libs in an OSS project is a nightmare
Sat Aug 6 08:56:13 CEST 2005
> > Problem 1 and the most severe and EASY TO FIX
> > From your website: "New, official "releases" are few and far between. In
> > short, if you want to work with FFmpeg, you are advised to go along with
> > CVS development rather than relying on formal releases." This is the key
> > problem. This is BAD ADVICE and a BAD POLICY. At least it is for the
> > libraries. Maybe this is acceptable for the command line tools which do
> > change user interface that much and where the user adjustment is keying
> > something different. But for the libraries changing API all the time this
> > is a nightmare.
>There is a solution to this problem available to you: Include a working
>CVS snapshot of FFmpeg in Motion. It's what many other projects
>building on FFmpeg do, at the very least all the players, i.e. MPlayer,
>xine, vlc, avifile, tcvp.
That is not a very good solution. Naturally that has been discussed in the
Motion team. Both placing known good ffmpeg sources and known good RPMs and
debs for download on the Motion sourceforge files page. And we probably
will do that.
But it is a very bad solution because ffmpeg is not just used for Motion.
If it was it was not a big issue. But ffmpeg is used for so many other
projects. Project that most people have and are using also. And it creates
nothing but errors, trouble, bug reports, people giving up when they both
have some old RPM of ffmpeg installed, and then install from sources from
some CVS snapshot. It is totally out of control.
I get support questions daily related to ffmpeg. I am so tired of this
situation. And I am sure maintainer of other project feels like I do.
90% of users download and install an RPM. Only few install from sources.
And then it always ends up with downloading some RPM from Dag, or ATRPMs or
Livna and then things break. MPlayer does not work or Motion does not work.
All the time because you guys change the API for the libs more often than I
change my underwear and with no change control, release notes, version
control whatsoever. Just a daily CVS snap. You really make it difficult -
almost impossible - to use the ffmpeg libs in other projects.
And the packagers do not know which ffmpeg snaps to release to they seem to
take a pick when encouraged to and the major packagers are not at all in
sync. Add to this Gentoo which relies on sources and you have a big mess.
ffmpeg is the ONLY open source project making shared libraries that are
this much out of control. Please listen to your users and try and learn. I
am sure you do not spend this much time on developing the code without
caring about if others can actually use the work project.
What does it take to do a release?
You have an automatic script making a "release" every day. What is it that
takes so long that you cannot give it a version number and upload it to the
Sourceforge file area?
If you start doing that - lets say every 3 or 6 months - the well known
packagers will for sure take only these and create their packages. You guys
only need to produce the source tar.gz.
Naturally you could do it the 100% automatic way. Just pick the snap from
31st of March = 0.4.9, 30th of June = 0.4.10, 30th of September = 0.4.11,
31st of December = 0.4.12.
It would be better than nothing.
Better would be to pick a known pretty good snap and release that.
There is always one more bug! There is always one more known problem not
yet resolved. If you wait for the day that ffmpeg is just perfect you will
The purpose of formal releases is to give the projects that depend on it -
and the end users - BASELINES. And to give us a some reasonable conditions
so that we known we do not have to fight with ever changing APIs. Just the
last 2 months I have had to update Motion TWICE because of libavformat API
changes. And I am only using the mpeg1 / mpeg4 / msmpeg4 codecs.
It is truely a nightmare and for you it is only a matter of spending 15
minutes to rename a date marked ffmpeg tar.gz and upload it to Sourceforge.
And if you want to do a little better job - an extra 15 minutes to write a
10-20 line release note listing new features AND changed APIs.
You really have no excuse for not doing it. It took me longer to write this
email than it took me to release last version of Motion.
I would recommend making a list of dates. Minimum twice a year. Max 4
times. Maybe 3 time is a good value.
Put these dates on the ffmpeg web site.
People know that the CVS of that day becomes next release so the developers
take a little care a week or two before not to break anything. And then
when the date arrives you take the 15 minutes to rename the tar.gz and
upload it to Sourceforge along with a brief release note.
It also makes it possible to uprev the shared lib packages without reaching
version 80 in a year because it would only be at the formal release date
that you would consider upreving the shared lib version. Shared lib version
control would make it possible for Motion to use one version and Mplayer to
use another. That is the whole idea of shared libs and many projects taking
advantage of the hard work done on a lib such as ffmpeg. You cannot
continue the "pick the last CVS" and "just pack a known good ffmpeg CVS
source tree with your sources". It does not do the job anymore.
kenneth at lavrsen.dk
Home Page - http://www.lavrsen.dk
More information about the ffmpeg-devel