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

[Jacob Meuser]

On Mon, Aug 08, 2005 at 12:50:10PM -0400, Rich Felker wrote:
> 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. 

there is/was already ffmpeg-acl.

> The problem is that everyone is using old crap
> and reporting bugs in old crap.

perhaps you did not read burkhard's email closely.  to me, it seems
he is talking about very regular (daily?) syncs.  trust me, burkhard
likes to keep things moving forward :)

besides, if I import ffmpeg sources into my project, then the ffmpeg
version used by whatever release of that project will only be as new
as that project's last release, where with shared libraries from an
external ffmpeg, I could update the ffmpeg version that project is
using (assuming there are no API/ABI problems with a newer version).

> There's already a PERFECT solution
> that works for everyone who's doing it: include lavc with your project
> and static link it.

I'll say it again, this does not work in all situations.

linking a non-PIC library into a _module_ on amd64 is a good example
of something that just won't work.

-- 
<jakemsr at jakemsr.com>