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

[Thomas Orgis]

Am Mon, 30 Mar 2009 21:11:04 +0000 (UTC)
schrieb Carl Eugen Hoyos <cehoyos at ag.or.at>: 

> Felipe Contreras <felipe.contreras <at> gmail.com> writes:
> 
> > >> Why? FFmpeg as is has quite a lot of limitations;
> > >
> > > Which limitations do you see?
> > 
> > Lack of run-time 3rd party plug-ins ala GStreamer?
> 
> And that is something that mpg123 supports / will support / should support iyo?

Wow... you never know where a discussion on this list is heading to.
Well, I am no binary plugin fanboi at the sight of easy accessible compilers and
source code... But actually mpg123 supports plugins for audio output.
Though that is mainly convenience for binary distributions, avoiding library
dependencies specific to some audio output hinder the mpg123 main application.
But that is irrelevant for MPlayer and ffmpeg anyhow as that simple plugin
system is outside the scope of the libmpg123 decoder.
More relevant could be the xmms2 plugin wrapping over libmpg123, which is not
3rd party, but is searched/loaded at runtime in xmms2.

But to come even more closer to relevance... I was thinking about specific usage
of the specific decoder API, certain features that a generic API is not necessarily
aware of. For example, the xmms2 plugin does not use the built-in equalizer in
libmpg123 which comes at zero CPU cost. Or the built-in handling of normalization
using parsed RVA values - again, directly in the decoder, not as postprocessing.
Of course such ways could be considered "hacks" and such effects can be done
externally, but sometimes you do not want to waste the CPU cycles to retransform the
data to apply an equalizer, or add a multiplication step for volume change.

But so far I see that there is some disagreement on whether one should link ffmpeg
to a decoder library for a format or write an internal codec... but in any case,
I suppose mp3lib shall be replaced with _something_ inside ffmpeg?


Alrighty then,

Thomas.

PS: I am aware of the usual case on a current GNU/Linux system with the software layer
of the ALSA library in default configuration burning more CPU cycles than the native
work of mpg123 anyway, without many people noticing... but there are uses where
you don't want to waste CPU cycles.

-------------- 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/20090331/09193030/attachment.pgp>