Some scenes (scenes with lots of motion) need more cpu power for decoding than the others.

You are not getting better playback here. When playing movies, we need to synchronize video with audio. Audio plays at normal speed. If cpu is not powerful enough, it will be unable to decode video frames fast enough and video will lag behind audio. Once this lag grows and exceeds some threshold, video player starts trying to skip some frames. The problem is that video frames often depend on the previous ones (see http://bmrc.berkeley.edu/frame/resea..._overview.html for some basic description). Only B-frames can be safely skipped. If the video does not contain B-frames at all, it needs to be sequentially decoded without skipping anything. You can force skipping frames anyway by using '-hardframedrop' mplayer option, but naturally you will get decoding artefacts. Though decoding can't be safely avoided in some cases, the player can skip displaying some frames on the screen to save time and catch up. Unfortunately (or luckily) video output takes only about 20% of cpu resources. So if cpu is slightly slower than needed (let's suppose it needs to be 10% faster to play some video file perfectly), all the frames can be decoded, but a fraction of them can be shown (for example, to get these extra 10% of cpu resources, half of the frames would have to be not displayed on screen). In the worst case, if the video is way too heavy, only I-frames will be shown occasionally, cpu will be overloaded trying to decode next frames and will never show them as it does not have any time left for that.

Pausing/resuming playback is not a good test and it does not prove anything. You resume playback, video plays a bit until it gets too far behind audio, framedropping comes into action and you get a slideshow.

In order to speedup decoding, video can be played in grayscale (using '-lavdopts gray' command line option) or at half resolution. Half resolution playback has horrible artefacts on ARM though, a lot worse than on x86. Maybe it is worth trying to figure out what's the matter (most likely it's some bug). Anyway, even on x86, half resolution playback has poor quality (you can try it with '-lavdopts lowres=1').

These settings affect postprocessing, mplayer does not use any postprocessing by default (so in the terms of DIVX, it already uses the lowest quality settings). Enabling postprocessing in mplayer will make it even slower.