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

Burkhard Plaum plaum
Mon Aug 8 14:12:49 CEST 2005

Interesting discussion. Actually, I can understand both
points of view. Including ffmpeg into an own project and
link statically solves all problems related to API/ABI
changes and versions. On the other hand, dynamic linking of
external libs is the preferred way for most OSS projects.

I use ffmpeg for 2 projects, libquicktime
(http://libquicktime.sourceforge.net) and gmerlin
(http://gmerlin.sourceforge.net) and I know what it means to
depend on ffmpeg.

The ffmpeg people do a great job for multimedia support on
Linux and other OSes. The developers make decisions, and it
doesn't make sense to discuss if they are right or not.

So my question is the following: Would forking be possible
without offending anyone? If there was another ffmpeg CVS
repository, which is automakified, but otherwise closely
synced with the primary CVS, regular releases can be made
from that. A smart shell script can sync the CVS almost
automatically, even if the build systems are different. If
some projects, which depend on ffmpeg, work together, the
amount of labor stays reasonable. The ffmpeg people can point
to these releases as "unsupported regular releases, using CVS
is preferred". The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.

Any opinions?

Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102

More information about the ffmpeg-devel mailing list