[mpg123-devel] Someone in for optimization of mpg123 binding to MPlayer?

[Thomas O. <tho...@or...>]

Hi folks,

recently, there's been discussion of finally removing the fork of
mpg123 code in MPlayer, called mp3lib. Blocking the way of that is the
current penalty that the mpg123 code gets when being used from MPlayer.

This is a general issue, but especially important for 3DNow machines
(old Athlon, K6), where this hit indeed makes the mpg123 decoding
slower than mp3lib. For SSE we got an advantage because of the fine
coding Taihei did --- mpg123's code simply is better there,
outweighing any penalty from the binding.

Now, there has been some discussion and analysis of this on the
MPlayer developer list, see thread starting at

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-September/069181.html

especially the discussion of this posting:

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-September/069206.html


Older history from when I contributed the mpg123 binding, also
pointing to the performance issues,is to be found here:

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-May/064656.html


Ivan made some tests and offered perf data in this post:

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2011-September/069237.html

Generally, the culprit seems to be increased Cache pressure. I'm not
sure how much of that could be attributed to inherent overhead in using
the library or dynamic linking (one can link recent mpg123 versions
statically to MPlayer to test that), but of course there is still the
wasteful copying of buffers to get the input data to mpg123.

I am aware of the bufferchain in use for the feeder not being an overly
optimal solution, I intended it as some way to replicate the old mpglib
kindof-library to ease porting towards the new libmpg123. Perhaps
hacking a way that moves the data to libmpg123 using pointers without
memcpy would help. Or the apparently suboptimal layout of the 3DNow (or
rather 3DNowExt) is to blame.

Anyhow, point of this post is that I severely lack the time to
investigate this, even to just digest the performance data Ivan
prepared. I have Real Life Stuff that really needs to be done instead.
But i really, really, want that settled. I want mpg123 to be the
fastest decoder. Period.

Would _you_ (yes, you;-) like to help bring mpg123 over this hurdle of
adoption in MPlayer? Perhaps your libmpg123-using app also suffers from
this (small) inefficiency that we are about to weed out. Or you just
live for the thrill of it --- profiling and chopping performance
bottlenecks, yay!

Do we have a volunteer, perhaps a horde of? I'd be so pleased, thankful
and simply glad.


Alrighty then,

Thomas.