Yes, but 16-bit multiplications are not the only operations in IDCT, you also need to load and store data for example. So performance improvement from using these instructions will never reach x2 factor in reality.

Sure, first you can check benchmark results provided by sdrman a few posts above and also my link with the results from 770. Decoding takes most of the time. Also it is easy to skip some frames on video playback if cpu power is not enough, but you can't skip decoding (so if your cpu is not fast enough to decode video in realtime, that's the worst case).

In addition, it is possible to profile mplayer with valgrind/callgrind (on x86 cpu, just to get general information about what parts of code take the most), or with gprof on real device. Some sample gprof output for mplayer on 770 can be found here: http://lists.mplayerhq.hu/pipermail/...ry/050363.html

In my tests IDCT usually takes 30% to 50% of video decoding time.

You can also check this article explaining video compression basics and performance considerations: http://www.dspdesignline.com/howto/b..._sel/187002884

I did some simulations with callgrind. Instructions cache should be enough for mpeg4, but there are many instruction cache misses for h264 (especially with cabac). And data cache is not enough for storing all the image buffers in it for sure, so many memory accesses in mplayer while decoding video are data cache misses.

You are welcome