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

[Thomas Orgis]

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.
 
> > We did port the 32bit SSE and 3DNowExt optimizations from MPlayer.
> > Is there something I overlooked in particular?
> 
> What about the AltiVec optimizations?

Oh, yeah. Those are included, too;-) Sorry that I forgot to mention.

> > 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.).
And, there are applications that are not interested in pictures at all, so
using a lib that can do more could be considered bloat;-)

> 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*)?
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?
Also, separate libs and players can exploit certain specfics of the
concerned formats that are not in the scope of a generic media player.

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.


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090330/c062ada3/attachment.pgp>