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

[Diego Biurrun]

On Mon, Mar 30, 2009 at 01:12:12PM +0200, Thomas Orgis wrote:
> Am Mon, 30 Mar 2009 12:38:38 +0200
> schrieb Diego Biurrun <diego at biurrun.de>: 
> 
> > On Mon, Mar 30, 2009 at 12:06:29PM +0200, Thomas Orgis wrote:
> > > I am not aware of additions that are missing. The official mpg123
> > > contains a load of bugfixes and enhancements, compared to the version
> > > the MPlayer mp3lib is derived from.
> > 
> > Which version is that?
> 
> Obviously something before I took over mpg123 maintainership;-)
> Either 0.59r or pre-0.59s (which added MMX)...
> 
> >  Did you inspect all the changes that were made
> > since?
> 
> I am aware that I will have to check this again in detail. But I am
> confident that there is nothing "big" missing.

You should at least go over the Subversion log for the mp3lib directory.
There were a bunch of small changes and fixes over the years.

> > > I am not familiar with ffmpeg code and what synergies it might bring.
> > 
> > FFmpeg is the world's multimedia engine.  Your code would be used by
> > everything that decodes pictures and sound basically.
> 
> Well, I know ffmpeg as such, but did not read the code to judge how far
> it is a good place to integrate mpg123 into (i.e. if one can significantly
> share code, if the result would still give access to all the features, etc.).

FFmpeg already has a fixed-point MP3 decoder, but it is slower than
mp3lib.  It also has a lot of optimizations for DCTs and other stuff
that could likely be shared and improve mpg123 further.

> And, there are applications that are not interested in pictures at all, so
> using a lib that can do more could be considered bloat;-)

You can compile FFmpeg with all video decoders and encoders disabled.

> > I don't see a point in having multiple competing libraries for each and
> > every multimedia format.  The wheel just gets reinvented dozens of
> > times.  FFmpeg already makes libmpeg2, liba52, libvorbis (for decoding),
> > libmad and soon libfaad obsolete.
> 
> 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.
The implementations should also be of the highest quality and speed.
For all the libraries I mentioned above this has been achieved.

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

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

> Anyhow, this discussion is rather theoretical at the moment, as 
> libmpg123 does exist and is maintained and it is most probably
> less work to replace the mp3lib with libmpg123 usage or instead make
> ffmpeg use libmpg123, than reworking the whole of libmpg123 to integrate
> it into ffmpeg directly. If that is what you mean.

The question is whether it would make more sense in the long run for you
to work on a floating-point MP3 decoder in FFmpeg instead of hacking on
mpg123 in isolation...

Diego