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

[Kenneth Lavrsen]

Dear Developers of ffmpeg

ffmpeg is a very nice project from a technical point of view

But from the view of a developer and project maintainer of a project that 
uses ffmpeg - the project is a nightmare.

My name is Kenneth Lavrsen. I maintain the project Motion which has been 
using ffmpeg for years now. (yes please add to the list).

http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome

Motion is a software motion detector. Motion is a program that monitors the 
video signal from one or more cameras and is able to detect if a 
significant part of the picture has changed; in other words, it can detect 
motion. Motion is a command line based tool whose output can be either 
jpeg, ppm fies or mpeg video sequences. It is made for Linux and FreeBSD.

I am receiving almost daily support requests all releated to people having 
problem building Motion with ffmpeg support. Besides the usual problem with 
people not having the -devel RPMs installed the most common problem is that 
they have downloaded the "latest CVS" of ffmpeg and get compilation errors.

And the answer is so often to install an older RPM or deb.

We try to keep up with the API changes in libavformat and libavcodec but 
there is now so many #ifdef statements in the code that I have lost control.
This is highly depressing and time consuming and the minute I found a 
useful alternative option I would stop using ffmpeg for Motion. And that is 
sad.

So what is the problem? There are two:

Problem 1 and the most severe and EASY TO FIX
The problem is that you guys running the ffmpeg project seems to be very 
little aware of the importance of very basic and simple software configuration
management.

 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.

ffmpeg is used very widely. People have ffmpeg installed for other reasons 
than Motion and often they cannot use those MUSEUM releases you have on the 
Sourceforge download site which you make less than once per year and never 
really fully do. The fact that 0.4.9pre1 never became 0.4.9 is rediculous.

As maintainer of a project that depends on libavcodec and libavformat: 
Please make more formal releases! Please make a formal release every time 
you add major new features.
The packagers such as Livna, AT and Dag - and the debian packagers will 
then take these and package and 99% of the users will use these.
And I as Motion maintainer will ensure to have my software working against 
the latest release.
I cannot do that today when the releases are so scarce.
And if that is too difficult for you to manage - then do the simplest of 
solutions. Take the CVS snapshot from each end of a quarter and give it one 
minor version number higher and upload it on Sourceforge. The daily snaps 
you have now are not manageable. I cannot check daily if Motion no longer 
works because of API changes or severe ffmpeg bugs.
At least with quarterly releases I could check and fix 4 times a year.

Please change this "latest CVS policy" and help both projects and packagers.


Problem 2. And I know you have heard this before.
Please document the API of the libraries!!!
The "look at the code example" is not sufficient. It is so dificult to code 
against the libraries and each time you change the API it is a pain for us 
to find out how to make our program work again and which #ifdef's to put in 
the code so it is backwards compatible to older ffmpeg versions. The 
Doxygen pages are not very useful. I might as well just try and read the code.

A last advice.
You should look at the Motion TWiki site. Making that was the best thing I 
ever did for the project Motion. And it enables putting the burden of 
maintaining API docs and users docs on many people incl users.
It has made maintaining release notes, maintaining and integrating patches 
etc a very easy task. I have even given up using the Sourceforge tracker 
because the TWiki applications I have made gives much more interaction and 
collaboration and it gives me and the other coders more time to code.
Look at the links below how I have made the API docs for the pwc driver for 
example. And for the Motion remote control API.


Regards
Kenneth Lavrsen

Project maintainer of Motion
http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
http://sourceforge.net/projects/motion/

Maintainer of the Wiki for the pwc driver
http://www.lavrsen.dk/twiki/bin/view/PWC/WebHome

API for Motion remote control
http://www.lavrsen.dk/twiki/bin/view/Motion/MotionHttpAPI


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