MPlayer: your system is too slow to play this!

Question

I just tried playing back a 1080p AVCHD video file recorded at 60 FPS with my Sony DSLR on my Ubuntu 12.04 workstation, and to my surprise MPlayer was not able to play the video smoothly. I copied the file to a local hard drive.

The video plays slower than it should and the A-V desync continues growing steadily (about 1 second of desync per 10 seconds of playback). One of the 8 CPU threads shoots up to 100%.

I was wondering if this is to be expected on my hardware. Its a little hard to believe, considering that my T60 laptop plays the video just fine, so I suspect software issues.

Workstation specs:

• CPU: Intel Quad Core i7-920 @2.67GHz
• GPU: Nvidia GeForce 9600 GSO 512
• RAM: 8Gb
• Compiz if functioning smoothly, although I have turned it off for this testing (no improvement in video playback)
• The system is generally lightning fast and responsive.
• Playing an MP4 with h264 1080p stream at 30 FPS works fine.

  
root@boss:~# glxinfo | grep direct
direct rendering: Yes

root@boss:~# glxinfo | grep vendor
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation

Mplayer output:

valprj@boss:~$ mplayer 00006.MTS 
MPlayer svn r34540 (Ubuntu), built with gcc-4.6 (C) 2000-2012 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing 00006.MTS.
libavformat version 53.21.1 (external)
Mismatching header version 53.19.0
TS file format detected.
VIDEO H264(pid=4113) AUDIO A52(pid=4352) SUB Teletext(pid=4608)  PROGRAM N. 1
FPS seems to be: 59.940060
Load subtitles in ./
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 53.35.0 (external)
Mismatching header version 53.32.2
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Unsupported PixelFormat 81
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1920x1080 => 1920x1080 Planar YV12 
A:   6.6 V:   6.1 A-V:  0.496 ct: -0.017 453/453 96% 10%  0.6% 221 0 


           ************************************************
           **** Your system is too SLOW to play this!  ****
           ************************************************

Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
  - Try -ao sdl or use the OSS emulation of ALSA.
  - Experiment with different values for -autosync, 30 is a good start.
- Slow video output
  - Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
  - Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
    e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
  - Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
  - Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
  - Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.

A:   7.8 V:   7.2 A-V:  0.602 ct: -0.017 520/520 97% 10%  0.6% 286 0 
[h264 @ 0x7fe0a0468380]concealing 136 DC, 136 AC, 136 MV errors
A:  17.1 V:  15.6 A-V:  1.495 ct: -0.017 1022/1022 97%  9%  0.6% 779 0 

Exiting... (Quit)

Things I tried

• Playing with -vc ffh264vdpau helped a bit. The desync ratio became 1 second of desync per 34 seconds of playback, and the video speed is almost right. The CPU usage went down significantly (20% on highest cpu thread). Yet I still get the:

  Your system is too SLOW to play this!

  message from MPlayer.

• Playing with -lavdopts skiploopfilter=all made the video play properly. The CPU hovers at around 93% and A-V sync hovers around 0.263s

Question

So my question is this - would you say it's reasonable for mplayer to have this much trouble playing back that video on my hardware, or do you figure that there is a software problem here? Maybe the nvidia driver?

Any ideas would be appreciated!

Answer 1

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

Answer 2

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!