[MPlayer-dev-eng] [PATCH] replacement for internal mpg123 fork (mp3lib), Final version?

[Uoti Urpala]

On Sun, 2010-05-16 at 18:03 +0200, Thomas Orgis wrote:
> Am Sun, 16 May 2010 12:10:46 +0200
> schrieb Diego Biurrun <diego at biurrun.de>: 
>  
> > Hmm, quick benchmarks on my K6-III show external mpg123 to be about
> > 20-25% slower.  What gives?
> 
> First: It's a bit unfortunate that it's apparently not possible to
> profile mplayer with gprof ... well, on x86 at least:

OProfile may be the best option.

> Long story short: mpg123 calls malloc() too often. It works with an
> internal linked list of buffers, allocating and freeing as new data
> arrives and old data is discarded. I am hesitating to use a fixed

> But what I could do, and what I did in mpg123 SVN, is to manage buffers
> with a minimal size of 4K instead allocating a new one for each bit of
> data that arrives. This brings the decoding time with mplayer for a set
> of reference files down to 12 seconds on my 1.2GHz Core2Duo compared to
> 12.7 seconds with mp3lib.

That much difference from a single extra malloc/free per mpeg frame?
That sounds unexpectedly large. Also MPlayer will allocate/free the data
for each packet anyway. Or did the mpg123 code do more extra than just
one allocation?


> In any case, you of course get the best performance of mpg123 with the
> latest version... as it should be the case with mplayer, too. We have a
> compromise to find between (theoretical?) raw throughput performance,
> A/V accuracy and compatibility to existing installs of libmpg123.
> Keeping it working correctly with old installs, but recommending the
> latest libmpg123 for best performance doesn't sound so bad for me.
> What do you think?

Sounds reasonable.


> PS: I checked again with valgrind if my mpg123 changes cause some
> memory mishap ... and accidentally ran mplayer with -ac mp3. Valgrind
> didn't like that:

Valgrind is known to fail on some code. AFAIK it's due to missing
support in Valgrind, though I haven't verified that.