MPlayer: your system is too slow to play this!

I'm not sure if you're still in need of assistance, but I'll post for future users... I believe the problem that you're having is that mplayer's default configuration only uses one processor core... Try passing the "-lavdopts threads=n" option (where 'n' is the number of threads to use).

mplayer -lavdopts threads=4 00006.MTS

TLDR? Ensure your CPU frequency governor is not being altered by some daemon or event-triggered script (e.g. a power management script).

History (boring)

I have had this problem on two different Ubuntu systems, especially when playing back h264/x264 videos. Video playback slows down, while audio continues as normal. Sometimes it catches up by itself, but sometimes it takes over 30 seconds before that happens!

Using a realtime chart of CPU usage, I noticed that CPU usage gets much larger when the problem occurs (at least as a proportion of the current frequency, which I am unfortunately not tracking).

One temporary fix is to interact with MPlayer, causing it to catch up fairly quickly, by using one of the following methods:

• Change playback speed by pressing [ then ]
• Switch in/out of fullscreen by pressing F twice
• Rewind and forward-wind by pressing Left then Right

But curiously when I wrote a script to send those keys automatically, the workaround did not catch up as expected! It appears actual physical interaction with the keyboard was required...

The cause: powersave governor!

Finally, I have found the problem was to do with CPU governor. It seems the script /etc/pm/power.d/cpu_frequency (on my Ubuntu 12.04) is intermittently setting the frequency governor to powersave, even though I remain plugged in to AC power. (This may be due to a software bug, or hardware, e.g. a dodgy power cable.)

Shortly afterwards (sometimes seconds, sometimes minutes) the script sets the governor back to ondemand, so it might not be easy to detect this happening! (I detected it by adding some logging into the script: echo "[$(date)] $0 was run with args $*" >> /tmp/cpu_frequency.log)

Temporary workaround (good for testing)

Initially I worked around the problem by running this little script in a terminal while watching a video:

while true; do cpufreq-set -c 0 -g performance ; cpufreq-set -c 1 -g performance ; sleep 2; done  

This script requires that you have the package cpufrequtils installed: sudo apt-get install cpufrequtils.

It simply ensures that the CPU will run at full speed at all times, enforced every 2 seconds. (Very occasionally I might see A/V lose sync for a moment, but then it catches up.)

As you can see, that script was written for two cores. But I have adapted this script to work for any number of cores:

#!/bin/bash
while [[ 1 ]]
do
  for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
  do
    [ -f $CPUFREQ ] || continue
    echo -n performance > $CPUFREQ
  done
  sleep 2
done

This does exactly the same thing, and doesn't require the cpufrequtils package, but it's not a one-liner.

Permanent solution

Rather than using one of those scripts above, we can instead make the solution more permanent, by disabling the script that is causing trouble.

One way to do that is to remove the troublesome script:

sudo rm  /etc/pm/power.d/cpu_frequency

But a less destructive way would be to edit the script. Simply add two lines somewhere near the top of the file:

# <date_here> Disabled by <your_name> to assist mplayer A/V sync
exit 0

But beware, this permanent solution will mean that the script won't switch to powersave when you really are unplugged from AC power, so your battery may not last as long as usual!

(Although on my system, an Asus X453M, it didn't actually switch to powersave permanently until the battery charge had dropped really low anyway.)

I hope this helps you. This problem was very frustrating for me!