[MPlayer-dev-eng] [PATCH] enable robust resync for mpg123 decoder

[Thomas Orgis]

Am Tue, 13 Jul 2010 17:12:29 +0200
schrieb Diego Biurrun <diego at biurrun.de>: 

> > I really would like to have found the reason for the rather
> > unusual performance hit MPlayer experiences compared to plain mpg123,
> > using the same decoding library.
> 
> What do you want me to investigate exactly?

A detailed profile of decoding with mp3lib vs. mpg123 in mplayer plus
comparison with the console mpg123 would be nice. I somehow failed to
get something really conclusive out of this, also regarding the strong
influence that this one-liner can have for MPlayer:

	perl -pi -e 's:aligned\(\d+\):aligned(64):g' mp3lib/*.c

The testing should show that standalone mpg123 is faster than mplayer,
and it might show that mplayer with mp3lib is faster than mplayer with
mpg123. The dealbreaker will be the difference in the profiles between
mplayer+mpg123 and standalone mpg123.
The comparison should be reasonably fair when decoding to nowhere:

time mplayer -ao pcm:file=/dev/null  -quiet -ac mpg123 *.mp3
time mpg123 -w /dev/null *.mp3

Given good profiling data, it should in theory be easy to find the spot
that wastes the CPU time. Actually... it might even be a better
comparison to time a simple example program that uses the same I/O path
to libmpg123 than the default ad_mpg123 in MPlayer does.

In the mpg123 distribution, there is doc/examples/mpglib.c (stand-alone
source, just link with -lmpg123). The timing then, would be along

time ./mpglib < input.mp3 > /dev/null

As it makes sense to give a rather big chunk of mp3 as input, one can
do cat *.mp3 | ./mpglib, too.

If you find a way to get a reliable, detailed profile of mplayer
against that mpglib program, that would be sweet. Ideally, the
libmpg123 part should be identical... leaving only the overhead... and
then one can have a look into why exactly this overhead is bigger as
for mp3lib.

You might want to test what happens when linking libmpg123 statically,
to be fair against mp3lib. For that you need a snapshot of mpg123's
svn trunk as I needed to rename internal non-static symbols that
clash with MPlayer.


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/20100713/b0d4e29d/attachment.pgp>