sound problems

[Jeff Spaleta]

On Tue, Jan 6, 2009 at 11:14 AM, Dominik 'Rathann' Mierzejewski
> That is a lie. There was one incompatible ABI/API change in the last three
> years and one move of headers.

So ffmpeg doesn't recommend using a static copy of ffmpeg libraries in
projects any more?

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2005-August/002999.html

Yes I know its an old post, but that's the sort of thing that people
bring up as a reference on how ffmpeg upstream works.

The header location change is certainly minor, but the impression
among application developers is that a common shared version of the
ffmpeg libs is still not the preferred way that upstream ffmpeg wants
application developers to use the libraries.  Just look at this recent
blog post:

http://blogs.gnome.org/bolsh/2008/12/05/ffmpeg-strikes-again/
Yes he got bit by the header location change...which is minor. But
look at all the responses from other application developers.  Multiple
people chiming in there complaining about how difficult it is to rely
consistently on ffmpeg svn checkouts.  Even a Moonlight developer,
which is a rather recent development effort in comparison to other
things, so the frustration with ffmpeg isn't completely a historical
artifact.

If there is a misconception about ffmpeg's relative instability
compared to other shared libraries...then ffmpeg developers need to
clarify this and actively encourage people to use a single shared
library across applications instead of continuing to let application
developers think that ffmpeg upstream encourages them to shove a
different static ffmpeg revision checkout into each and every
application.

It's the same blasted problem that is plaguing xulrunner applications
right now.  We can't have upstreams encouraging people to cart around
static copies of slightly different revision of the same library. We
need application developers to be targeting the use of shared
libraries and if ffmpeg developers are willing to help make that
possible, then please, please get them to put a public statement out
about that on the ffmpeg website with instructions for application
developers on how to file and fix issues with regard to using a single
shared system library instead of a per-application ffmpeg revision.

-jef