Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just compiled mplayer2 from source (git://git.mplayer2.org/mplayer2-build.git) because the repository (ubuntu 12.04) version didn't work on my system. Since I have old hardware I was just wondering if there are some compiler flags I could use to optimize it for my hardware.

The CPU is an Athlon XP 2200+ (mobile), 1GB RAM, graphics: Nvidia GeForce4 420 Go.

I also want to do the same on another old system with similar specs:

CPU: Athlon 1,2 GHZ, 1GB RAM, graphics: [SiS] 65x/M650/740

share|improve this question
up vote 1 down vote accepted

General recommendation

If the version taken from your distribution repository of mplayer2 doesn't work for you, it is a good thing to report what didn't work to the bug tracking system, so that it has benefits for both you and others:

  • It gets fixed for your hardware in this release of your distribution.
  • It will (with high probability) work when you upgrade to a newer version of the distribution, without having to worry.
  • It will benefit others that may have the same problem but, as you, have not taken the task of reporting the error.

Recompilation on a particular system

Recompiling the program specifically for your machines is likely to have better results than the "generic" flavor that a distribution releases (this is, BTW, one of the motivations that the Gentoo folks have when they recompile things to their own systems).

Of course, you may gain some improvements in speed, but you loose the portability of the binaries.

The generic compilation

That being said, the general way recompiling a program in a current Debian/Ubuntu system is to take the source package and its build dependencies with something as:

sudo apt-get build-dep mplayer2
sudo apt-get install fakeroot
apt-get source mplayer2

then edit the file debian/rules inside the directory created by the last command to change the values that go in the CFLAGS, CPPFLAGS, CXXFLAGS, and LDFLAGS.

What can you do to tailor the application to your machines? You will have to experiment (read: "measure/benchmark", see below) with which level of optimization (like -O2, -Os, or -O3) the program runs faster.

To actually compile the program, you will need to run, inside the directory created by the apt-get source mplayer2 command:

fakeroot debian/rules binary
sudo dpkg -i ../*.deb

With GCC versions 4.7 or newer, you can even experiment with the -Ofast compilation level, which for playing videos is not going to cause too much harm, but which can give you some improvements (enough to not accumulate frames and get audio and video out of sync).

The system/hardware specific parts of the compilation

To compile the program specifically for the machine where you will be executing it, it is a good thing to use GCC's -mach=native flag. This will probably make the binaries produced unuseable in other systems, but as long as you care only for your system, that's the way to go.

Just to give you an idea of what options are enabled on my Core i5-2410M when I use -march=native, see (output reformatted to not destroy the layout of the site):

gcc -march=native -E -v - < /dev/null 2>&1 | grep cc1
/usr/lib/gcc/i486-linux-gnu/4.7/cc1 -E -quiet -v -imultiarch i386-linux-gnu - \
  -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt \
  -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 \
  -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rdrnd \
  -mno-f16c -mno-fsgsbase --param l1-cache-size=32 \
  --param l1-cache-line-size=64 \
  --param l2-cache-size=3072 -mtune=corei7-avx

From there you can see that GCC detected some "advanced" instructions that my computer has (AVX) and others that it doesn't have (AVX2).

How to measure the results

As a hint, to benchmark, just play a short video, say, foo.mkv with:

mplayer -benchmark -vo null -nosound foo.mkv

This will "play" the video as fast as your system can and tell you how many seconds it took to "play" the video in its entirety. Note that I said "play" in quotes, because we are disabling:

  • The sound decoding with -nosound. Usually minor time is spent here, in comparison to the other parts of playing a video.
  • The time taken to actually display the video (-vo null).

To see if the video card is getting in the way or not, you can omit the -vo null part from the command above and see if the video you want plays faster than real-time (or whatever your goal is).

Some final words, part 1: the specific case of mplayer2

That being said, much of mplayer2 (and regular mplayer, when this later one is taken from distributions) is that most of their processing is "offloaded" to libraries. In particular, a lot of the decoding is made by libav or ffmpeg, and those are the packages that should be compiled/optimized in the first place.

In the case of "vanilla" mplayer (not mplayer2) taken from upstream, it uses embedded copies of many libraries, which means that, if you compile it from the upstream sources (instead of the method that I gave you above with apt-get source mplayer2 etc), it will also compile its own libav/ffmpeg and have the potential of being much faster than the alternatives.

Some final words, part 2: getting some gains without recompiling

It is not always necessary to recompile the mplayer/mplayer2 binaries provided by your distribution if you change a few configuration parameters. To avoid all the work above, I would begin by playing the videos with something like:

mplayer -framedrop -lavdopts fast:skipframe=nonref:skiploopfilter=nonref foo.mkv

Of course, you can play with the options that I just gave you and the manpage documents the possible values for skipframe and skiploopfilter, among other things.

And happy watching videos!

share|improve this answer
Thanks. Great answer! In the case of mplayer2: If I compile it from upstream it doesn't compile libav/ffmpeg from source, is this correct? So I would have to compile libav and ffmpeg from source seperatly even if I use the upstream mplayer2 sources? – student Nov 10 '12 at 12:03
Yes, mplayer2 decoupled itself as much as possible from the libraries that mplayer bundles and, as a result, you would not gain much from recompiling it (well, you may try, though, as it should compile moderately quickly). But the options to be passed to -lavdopts are likely to have more impact, as they skip entire parts of pipelines, in some cases. – rbrito Nov 10 '12 at 15:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.