sound problems

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 06 January 2009 at 21:41, Jeff Spaleta wrote:
> 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?

I haven't seen any such statements from the developers for a long time now.
ABI and API changes are watched carefully and breakage is postponed for
next major version bump as far as I can tell.

> 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.

Let me reply with a link to a blog post by one of FFmpeg's developers
then: http://multimedia.cx/eggs/we-dont-care-we-dont-have-to/

> 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.

Well, given the rapid development rate of FFmpeg, a statically linked
snapshot is not a bad solution. FFmpeg developers don't really care
if you use a static or shared version, as long as you don't report
problems with an old version to them. 

I think this is where the distribution packagers have to come in. I try
to keep up with FFmpeg's latest version in RPMFusion/devel, but both
F-10 and F-9 branches carry an older snapshot, from before the ABI change.

> 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.

I think the current snapshots are well-suited to be built as shared
libraries and I haven't seen any issues related to using them other than
applications (ab)using FFmpeg's private API. This is the reason why
e.g. MPlayer is still built using a static copy of FFmpeg's libraries.

I'm not really sure what you're expecting with regard to "a public statement
about that on the FFmpeg website" etc, though.

Regards,
R.

PS. Please use the correct capitalization of the name FFmpeg in the future.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"