2smackpotato: don't know, Nokia 770 uses gstreamer multimedia framework, don't know if mplayer can use gstreamer plugins directly (but mplayer probably can be patched to make some use of them)

2fanoush: Thanks, that is interesting idea. Anyway, we are probably already at ARM core limits (though maybe some time critical parts of decoder can be optimized using armv5 edsp instructions, mplayer uses only armv4 in assembly optimized code fragments). Now in order to improve performance, it would be a good idea to move some work to DSP core (preferably moving color conversion/scaling work to it). We can either try finding a way of using existing DSP based audio codecs from mplayer, or try it the other way around - experiment with compiling ffmpeg based gstreamer plugin and replacing default mpeg4 DSP based decoder with it.

As we don't have a free toolchain for DSP programming, most of the nontrivial parts of code and complicated video codecs would have to be implemented using ARM core. But scaling/color conversion seems to be a relatively simple and well defined task that could be implemented using DSP and reused for any codec. I wonder if DSP can have access both to a memory fragment with a frame decoded by ARM core and to video memory buffer to do this work (from what I read, DSP is only 16-bit cpu, I wonder what addressing modes it supports). And this task could be run simultaneously with decoding the next frame.

Well, everything written above is just a pure speculation It is only a few days passed since I even had a look into mplayer internals. And I have absolutely no prior knowledge about multimedia compression algorithms or even color formats, so I'm sorry for possibly posting here some stupid things All that started from 'hey, it is quite easy to compile mplayer, here is the binary' and turned into fine tuning it into something useful in the end