[Ffmpeg-devel] Using ffmpeg libs in an OSS project is a nightmare

Kenneth Lavrsen kenneth
Sat Aug 6 08:56:13 CEST 2005


>Added.
>
> > 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 
> not
> > 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 
die unhappy.
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


-- 
Kenneth Lavrsen,
Glostrup, Denmark
kenneth at lavrsen.dk
Home Page - http://www.lavrsen.dk 






More information about the ffmpeg-devel mailing list