We made a short document describing all the necessary details. Please follow the instructions.

Read the translation HOWTO, it should explain everything. You can get further help on the MPlayer-docs mailing list.

We are more than happy to accept your hardware and software donations. They help us in continuously improving MPlayer.

We always welcome coders and documenters. Read the technical documentation to get a first grasp. Then you should subscribe to the MPlayer-dev-eng mailing list and start coding. If you want to help out with the documentation, join the MPlayer-docs mailing list.

We have a modular, handwritten build system. It does a reasonably good job, so why change? Besides, we dislike the auto* tools, just like other people.

You have stumbled over a bug in gcc. Please report it to the gcc team but not to us. For some reason MPlayer seems to trigger compiler bugs frequently. Nevertheless we cannot fix them and do not add workarounds for compiler bugs to our sources. To avoid this problem, either stick with a compiler version that is known to be reliable and stable, or upgrade frequently.

See the Debian and RPM section for details.

Try the following configure options:

./configure --target=athlon_xp --cc="gcc -m32" --as="as --32" --with-extralibdir=/usr/lib

This is a known problem of gcc 3.2, upgrade to 3.3 to solve the problem. How to install gcc is described in the gcc 2.96 section. Alternatively you can use an external FAAD library as described in the AAC section.

This is a known problem of gcc 3.0.4, upgrade to 3.1 to solve the problem. How to install gcc is described in the gcc 2.96 section.

Your gcc isn't installed correctly, check the configure.log file for details.

We strongly discourage the use of gcc 2.96! Read this document for details about why Red Hat released gcc 2.96 and what the problems are all about. If you still really really want to use it, be sure to get the latest release and give the --disable-gcc-checking option to configure. Remember that you are on your own from this point. Do not report bugs, do not ask for help on the mailing lists. We will not provide any support in case you run into problems.

No, since there have been/are issues with these compilers as well. To check the status of current compilers' MPlayer support, see the Installation section.

Quoted from a mail A'rpi sent to the MPlayer-users list (the word 'ideg' is described below):

And we have idegs. And our idegcounter overflowed again and again.

Unfortunately MPlayer is out of our control. It's used by lamers, Linux users who can't even use Windows, and never tried to compile a kernel. They installed (with default options) Mandrake or Red Hat or SuSE, and without RTFM'ing they send messages saying 'it doesn't work! help me! please! i'm new to Linux! help! oh! help me!'. We can't stop them, but at least we try to force them to RTFM and to read the messages of ./configure and MPlayer.

And you clever guys come and flame us with gcc 2.96 and binary packages. Instead of helping users or making patches to help solve problems.

Half of our spare/free time is spent by answering silly mails here and making newer tricks and checks to configure to avoid such mails.

And there is a balance. On the one side are you, clever guys, saying we are very bad because we don't like buggy gcc 2.96, and on the other side there are the 'new to Linux' guys who are showing us gcc 2.96 is buggy.

Conclusion: We can't be good. Half the people will always say we are bad.

Maybe we should close the project, make it closed source, commercial, and provide install support for it. then we could leave current work, so development could go faster, and we could earn lots of money with it and buy a big house, etc etc. Do you really want it? It seems.

It was tested to work with SDL 1.2.x and may run on SDL 1.1.7+. It does not work with any previous version. So if you choose to use such a version, you are on your own.

Where did you install the SDL library? If you installed in /usr/local (the default) then edit the top level config.mak and add -L/usr/local/lib after X_LIBS=. Now type make. You're done!

Read the mga_vid section.

... but you don't have the X development package installed. Or not correctly. It's called XFree86-devel* under Red Hat, and xlibs-dev under Debian Woody, libx11-dev under Debian Sarge. Also check if the /usr/X11 and /usr/include/X11 symlinks exist (this can be a problem on Mandrake systems). They can be created with these commands:

     # ln -sf /usr/X11R6 /usr/X11
     # ln -sf /usr/X11R6/include/X11 /usr/include/X11

You have to edit SVGAlib's Makefile.cfg and comment BACKGROUND = y out.

Add /usr/local/lib to /etc/ld.so.conf and run ldconfig.

This is a linker problem. Upgrading binutils should help (2.11.92.* or newer should be good). Since it is not our fault, please do not report!

chmod 644 /usr/lib/libc.so

Me too. :)

Yes. See the mailing lists section.

Please read the bug reporting guidelines and follow the instructions.

Check the codec status, if it doesn't contain your codec, read the codec documentation, especially the codec importing HOWTO and contact us.

You need root privileges or a specially set up kernel to use the new timing code. For details see the RTC section of the documentation.

You have to use a video output driver that does not employ an overlay to be able to take a screenshot. Under X11, -vo x11 will do, under Windows -vo directx:noaccel works.

Press o and try the -osdlevel option.

It does, but you have to explicitly specify software scaling (very slow) with the -zoom option. You better use XF86VidMode support: You must specify the -vm and the -fs option, and you're done. Make sure you have the right modelines in your XF86Config file, and try to make the DGA driver and SDL's DGA driver work for you. It's much faster. If SDL's DGA works, use that, it'll be even faster.

Example:

A: 2.1 V: 2.2 A-V: -0.167 ct: 0.042 57/57 41% 0% 2.6% 0 4 49%

Most of them are for debug purposes and will be removed at some point.

Use the -quiet option and read the man page.

It's not zero, but it's called from the codec and thus cannot be measured separately. You should try to play the file using -vo null and then -vo ... and check the difference to see the video_out speed.

You are using Direct Rendering, where the codec renders to the video memory itself. In this case, the decoding percentage contains the display percentage, too.

Download the Win32 codecs from our codecs page (avifile's codec package has a different DLL set) and install it.

A combination of a Hungarian and an English word. "Ideg" in Hungarian means the same as "nerve" in English, and is pronounced as something like "ydaegh". It was first used to measure the nervousness of A'rpi, after some (umm) "mysterious" disappearance of CVS code ;)

"Fasz" is a Hungarian word you don't want to know, the others are connected to the perverted minds of the MPlayer developers.

After running ./configure, edit config.h and replace #undef FAST_OSD with #define FAST_OSD. Then recompile.

See the libavcodec section.

You need to get libavcodec from FFmpeg's CVS. Read the instructions in the libavcodec section.

Are you using FVWM? Try the following:

Use:

mplayer options filename < /dev/null &

Do you have a stray codecs.conf file in ~/.mplayer/, /etc/, /usr/local/etc/ or a similar location? Remove it, an outdated codecs.conf file can cause obscure problems and is intended for use only by developers working on codec support. It overrides MPlayer's internal codec settings, which will wreak havoc if incompatible changes are made in newer program versions. Unless used by experts it is a recipe for disaster in the form of seemingly random and very hard to localize crashes and playback problems. If you still have it somewhere on your system, you should remove it now.

You have to use -aid (audio ID) or -alang (audio language), -sid(subtitle ID) or -slang (subtitle language), for example:

mplayer example.mkv -alang eng -slang eng
mplayer example.mkv -aid 1 -sid 1

mplayer -vo null -ao null -frames 0 -v filename | grep sid
mplayer -vo null -ao null -frames 0 -v filename | grep aid

Try playing the stream with the -playlist option.

Your file is most probably broken or a fake file. If you got it from a friend, and he says it works, try comparing md5sum hashes.

Just change your video output device. Issue the following command to get a list of available video output drivers:

mplayer -vo help

 vo = selected_vo

vo_driver = selected_vo

Make sure you have installed fonts properly. Run through the steps in the OSD and subtitle part of the installation section again. If you are using TrueType fonts, verify that you have the FreeType library installed. Other things include checking your subtitles in a text editor or with other players. Also try converting them to another format.

There is a bad interaction on Fedora between exec-shield, prelink, and any applications which use Windows DLLs (such as MPlayer).

The problem is that exec-shield randomizes the load addresses of all the system libraries. This randomization happens at prelink time (once every two weeks).

When MPlayer tries to load a Windows DLL it wants to put it at a specific address (0x400000). If an important system library happens to be there already, MPlayer will crash. (A typical symptom would be a segmentation fault when trying to play Windows Media 9 files.)

If you run into this problem you have two options:

MPlayer is not xine/vlc/.... Although these players have some code in common, the codecs (DLL) set, synchronization, demultiplexing etc is different and should not be compared. If you have a file MPlayer fails to play correctly but works in another player, please read the bug reporting guidelines and upload the file to our FTP server.

Try the -bps or -nobps option. If it does not improve, read the bug reporting guidelines and upload the file to FTP.

Check ldd /usr/local/bin/mplayer output. If it contains

libc.so.6 => /lib/libc.so.6 (0x4???????)

libc.so.6 => /lib/libc.so.6 (0x00??????)

Your machine is too slow or your sound card driver is broken. Consult the documentation to see if you can improve performance.

Try running MPlayer on the machine you compiled on. Or recompile with runtime CPU detection (./configure --enable-runtime-cpudetection). Don't use MPlayer on a CPU different from the one it was compiled on, without using the feature mentioned just now.

Read the bug reporting guidelines and send us a proper bug report. Also try experimenting with the -fstype option.

You have an old version of codecs.conf in ~/.mplayer/, /etc/, /usr/local/etc/ or similar. Remove it, it's not needed anymore. OR you have the vc= option or something similar in your config file(s).

The KDE arts sound daemon is blocking the sound device. Either wait until the video starts or disable the arts-daemon in control center. If you want to use arts sound, specify audio output via our native arts audio driver (-ao arts). If it fails or isn't compiled in, try SDL (-ao sdl) and make sure your SDL can handle arts sound. Yet another option is to start MPlayer with artsdsp.

It's not a DivX file, but an MS MPEG4v3. If you have an old version of codecs.conf in ~/.mplayer/, /etc/, /usr/local/etc/ or similar, remove it.

This can have multiple reasons.

Use another codec to play the file, try -vc ffmjpeg.

Your card probably reports some colorspaces as supported when in fact it does not support them. Try with YUY2 instead of the default YV12 (see the TV section).

You have a buggy sound card/driver. Most likely it's fixed at 44100Hz, and you try to play a file which has 22050Hz audio. Try the resample audio filter.

If you have an old version of codecs.conf in ~/.mplayer/, /etc/, /usr/local/etc/ or similar, remove it.

It's an effect of the power management / power saving system of your notebook (BIOS, not kernel). Plug the external power connector in before you power on your notebook. You can also try whether cpufreq (a SpeedStep interface for Linux) helps you.

This is again a power management effect (see above). Plug the external power connector in before you power on your notebook or use the -nortc option.

Badly interleaved files and -cache don't work well together. Try -nocache.

You have to use -rawaudio on:format=0x50.

After setting up your asoundrc you have to use -ao alsa:device=dmix.

Are you running KDE or GNOME with the ARTS or ESD sound daemon? Try disabling the sound daemon or use the -ao arts or -ao esd option to make MPlayer use ARTS or ESD. You might also be running ALSA without OSS emulation, try loading the ALSA OSS kernel modules or add -ao alsa to your command line to directly use the ALSA audio output driver.

./configure autodetects your DGA driver. If -vo help doesn't show DGA, then there's a problem with your X installation. Try ./configure --enable-dga and read the DGA section. Alternatively, try SDL's DGA driver with the -vo sdl:dga option.

It works only if running as root! It's a DGA limitation. You should become root (su -), and try again. Another solution is making MPlayer SUID root, but it's not recommended!

     chown root /usr/local/bin/mplayer
     chmod 755 /usr/local/bin/mplayer
     chmod +s /usr/local/bin/mplayer
 

The tdfx driver in XFree86 4.0.2/4.0.3 had this bug. This was solved by bug fix #621 of the XFree86 4.1.0 CVS log. So upgrade to XFree86 4.1.0 or later. Alternatively, either download (at least) DRI version 0.6 from the DRI homepage, or use CVS DRI.

Your OpenGL driver doesn't support dynamic texture changes (glTexSubImage). It's known not to work with nVidia's binary mess. It's known to work with Utah-GLX/DRI and Matrox G400 cards. Also with DRI and Radeon cards. It won't work with DRI and other cards. it will not work with 3DFX cards because of the 256x256 texture size limit.

This is a bug of nVidia's binary X driver. These bugs appear ONLY with the TNT/TNT2 cards, and we can't do anything about it. To fix the problem, upgrade to the latest nVidia binary driver version. If still bad, complain to nVidia!

Yes, nVidia corrected a previous bug (above), and introduced a new one. Let's congratulate them. UPDATE: According to nVidia, this has already been fixed.

Try that x11 target again. Now try -vo x11 -fs -zoom. See the difference? No?! OK, here comes the enlightenment: SDL's x11 target uses xv when available, you don't have to worry about it ... Note: With SDL you can force/disable Xv using -forcexv and -noxv.

MPlayer does not support DVD menus due to serious architectural limitations that prevent proper handling of still images and interactive content. If you want to have fancy menus, you will have to use another player like xine, vlc or Ogle. If you want to see DVD navigation in MPlayer you will have to implement it yourself, but be aware that it is a major undertaking.

This is a known libdvdread 0.9.1/0.9.2 bug. Use libmpdvdkit2, which is present in MPlayer source, and used by default.

Who knows ... It's said to work, so please test it and send feedback. Refer to the documentation of libdvdread and its homepage as well. We're not the authors of libdvdread. Use libmpdvdkit2, which is present in MPlayer source, and used by default.

Yes. See the DVD chapter.

Use the regionset tool.

No. However you must have the proper rights on the DVD device entry (in /dev/).

You don't need to. Use libmpdvdkit2, which is present in the MPlayer source, and used by default. You can get the mentioned packages from the Ogle site.

Yes, try the -chapter option.

Use the -cache option (described in the man page) and try enabling DMA for the DVD drive with the hdparm tool (described in the CD chapter).

Use the -dvd-device option to refer to the directory that contains the files:

mplayer dvd://1 -dvd-device /path/to/directory

This is very tricky to implement without losing A/V synchronization. All attempts have failed so far, but patches are welcome.

You can step forward one frame by pressing .. If the movie was not paused it will be paused afterwards (see the man page for details). Stepping backwards is unlikely to be implemented anytime soon.

Create a file named movie.avi.conf with the file-specific options in it and put it in ~/.mplayer or in the same directory as the file.

Read the MEncoder section.

Try the mencvcd script from the TOOLS subdirectory. With it you can encode DVDs or other movies to VCD or SVCD format and even burn them directly to CD.

MPEG files can be concatenated into a single file with luck. For AVI files, you can use MEncoder's multiple file support like this:

mencoder -ovc copy -oac copy -o out.avi file1.avi file2.avi

Simply copy the video and audio streams into a new file, and MEncoder generates the index. Of course this cannot fix possible bugs in the video and/or audio streams. It also fixes files with broken interleaving, thus the -ni option will not be needed for them anymore.

mencoder -idx input.avi -ovc copy -oac copy -o output.avi

You have to specify the -sid option correctly!

Use the -chapter option correctly, like: -chapter 5-7

No, VFAT doesn't support 2GB+ files.

Because the bitrate you encoded the audio with is too large to fit the movie on any CD. Check if you have libmp3lame installed properly.

Because ASF uses variable frame rate but AVI uses a fixed one, you have to set it by hand using -ofps.

Just pass the -sub <filename> (or -sid, respectively) option to MEncoder.

It's not possible directly, but you can try this (note the & at the end of mplayer command):

    mkfifo encode
    mplayer -ao pcm -aofile encode dvd://1 &
    lame your_opts encode music.mp3
    rm encode