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

Rich Felker dalias
Mon Aug 8 18:50:10 CEST 2005

On Mon, Aug 08, 2005 at 02:05:19PM +0200, Burkhard Plaum wrote:
> 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.

This is just as bad. The problem is that everyone is using old crap
and reporting bugs in old crap. There's already a PERFECT solution
that works for everyone who's doing it: include lavc with your project
and static link it.


More information about the ffmpeg-devel mailing list