[MPlayer-dev-eng] mpg123 / mp3lib 64bit SSE code

[Uoti Urpala]

On Mon, 2009-03-30 at 13:40 +0200, Diego Biurrun wrote:
> On Mon, Mar 30, 2009 at 01:12:12PM +0200, Thomas Orgis wrote:
> > So it reimplemented all those codecs? Is the target of ffmpeg to include
> > all codec work in it's source or will it continue to also use external
> > libraries (*cough* that manage to do official releases and maintain the
> > API *cough*)?
> 
> FFmpeg's goal is to have native decoders for all multimedia formats.

But it's not that obvious whether the "nativeness" actually is such an
useful goal.

> The implementations should also be of the highest quality and speed.
> For all the libraries I mentioned above this has been achieved.

So the people working on FFmpeg have managed to create libraries that
compare well to some of the alternatives. That doesn't really say
anything about whether moving a working project under FFmpeg would be
beneficial. I'd expect it to have mostly negative direct effects, but it
could have the positive side of getting more attention from people
following FFmpeg development (and so help future recruitment of people).

> > I understand that you don't want to have every media player depend on
> > an endless number of decoding libs and rather prefer working through
> > one interface, that of ffmpeg, for example. But that does not mandate
> > that the separate libraries should not exist at all... or does it?
> 
> Nowadays I see decoders outside FFmpeg as a waste of time.

Why? FFmpeg as is has quite a lot of limitations; I'd say it's clearly
wrong to expect all multimedia code to run under its infrastructure
(having FFmpeg interfaces to separately usable libraries would be
better, but FFmpeg seems to avoid that...).

> > Also, separate libs and players can exploit certain specfics of the
> > concerned formats that are not in the scope of a generic media player.
> 
> What specifics would that be?  FFmpeg already has many format-specific
> optimizations and many general ones that are shared.

FFmpeg has optimizations yes, but not the API access to the specifics.
It tries to fit every format in the same square hole, and _only_ the
same square hole. Having a uniform API available for generic
functionality is positive; having _only_ a single uniform API that
cannot possibly support all the specifics is negative.

If you have a general "library for working with MP3 audio" you'll want
it to have more than a straightforward decoding interface. And FFmpeg
doesn't really support exporting such format-specific functionality.