[MPlayer-dev-eng] [PATCH] remove mp3lib

[Ivan Kalvachev]

On 1/30/12, Thomas Orgis <thomas-forum at orgis.org> wrote:
> Am Tue, 13 Dec 2011 22:56:05 +0100
> schrieb Thomas Orgis <thomas-forum at orgis.org>:
>
>> On the actual topic of my investigations... I am still hunting the
>> reason why gcc produces inferior binary from mpg123's sources compared
>> to mp3lib... even when the concerned code is the same (well,
>> basically...). This will be a christmas/new year thing... but hopefully
>> I can resolve it.
>
> Just a heads-up, I'm spending spare minutes on this as I can. I am
> documenting my efforts on
>
> 	http://mpg123.org/beating_mp3lib_in_mplayer/
>
> Suggestions welcome...

I've read it and I must say I'm impressed by the work you've done so far.

If I understood correctly the major slowdown is caused by
WRITE_SAMPLE() that basically clips a float and writes it as (short).

Then the inefficient code is used as basis for writing the "hand"
assembly version in synth_i586.S.
The funny thing is that mp3lib/decode_i586.c seems to contain equally
inefficient assembler code o_O

There is another trick to saturate floats to short range and convert
them to integer.

Take a look of ffmpeg/libavutil/common.h::av_clip_int16_c . For some
hints how to use single if() to check for clipping.
It is based on {if((unsigned)(x+min) > (max+min) ) x=clip(x);}


Another unrelated hint, FFmpeg also uses bit context structures and
one optimization involving them is to group the frequently accessed
member together, so they share cache lines (and stay in the cache for
longer).

Keep the good work.