Flame Wars - MPlayer - The Movie Player for Linux

In medias res

There are two major topics which always cause huge dispute and flame on the mplayer-users mailing list. Number one is the topic of the

GCC 2.96 series

The background: The GCC 2.95 series is an official GNU release and version 2.95.3 of GCC is the most bug-free in that series. We have never noticed compilation problems that we could trace to gcc-2.95.3. Starting with Red Hat Linux 7.0, Red Hat included a heavily patched CVS version of GCC in their distribution and named it 2.96. Red Hat included this version in the distribution because GCC 3.0 was not finished at the time, and they needed a compiler that worked well on all of their supported platforms, including IA64 and s390. The Linux distributor Mandrake also followed Red Hat's example and started shipping GCC 2.96 with their Linux-Mandrake 8.0 series.

The statements: The GCC team disclaimed any link with GCC 2.96 and issued an official response to GCC 2.96. Many developers around the world began having problems with GCC 2.96, and started recommending other compilers. Examples are Apache, MySQL, avifile and Wine. Other interesting links are Real time Linux, Linux kernel news flash about kernel 2.4.17 and Voy Forum. MPlayer also suffered from intermittent problems that were all solved by switching to a different version of GCC. Several projects started implementing workarounds for some of the 2.96 issues, but we refused to fix other people's bugs, especially since some workarounds may imply a performance penalty.

You can read about the other side of the story here. GCC 2.96 does not allow | (pipe) characters in assembler comments because it supports Intel as well as AT&T Syntax and the | character is a symbol in the Intel variant. The problem is that it silently ignores the whole assembler block. This is supposedly fixed now, GCC prints a warning instead of skipping the block.

The present: Red Hat says that GCC 2.96-85 and above is fixed. The situation has indeed improved, yet we still see problem reports on our mailing lists that disappear with a different compiler. In any case it does not matter any longer. Hopefully a maturing GCC 3.x will solve the issue for good. If you want to compile with 2.96 give the --disable-gcc-checking flag to configure. Remember that you are on your own and do not report any bugs. If you do, you will only get banned from our mailing list because we have had more than enough flame wars over GCC 2.96. Please let the matter rest.

If you have problems with GCC 2.96, you can get 2.96-85 packages from the Red Hat ftp server, or just go for the 3.0.4 packages offered for version 7.2 and later. You can also get gcc-3.1 packages (unofficial, but working fine) here and you can install them along the gcc-2.96 you already have. MPlayer will detect it and use 3.1 instead of 2.96. If you do not want to or cannot use the binary packages, here is how you can compile GCC 3.1 from source:

Go to the GCC mirrors page page and download gcc-core-3.1.tar.gz. This includes the complete C compiler and is sufficient for MPlayer. If you also want C++, Java or some of the other advanced GCC features gcc-3.1.tar.gz may better suit your needs.
Extract the archive with
tar -xvzf gcc-core-3.1.tar.gz
GCC is not built inside the source directory itself like most programs, but needs a build directory outside the source directory. Thus you need to create this directory via
mkdir gcc-build
Then you can proceed to configure gcc in the build directory, but you need the configure from the source directory:
cd gcc-build ../gcc-3.1/configure
Compile GCC by issuing this command in the build directory:
make bootstrap
Now you can install GCC (as root) by typing
make install

Binary distribution of MPlayer

This was the second big problem but has been solved as of version 0.90-pre1. MPlayer previously contained source from the OpenDivX project, which disallows binary redistribution. This code has been removed and you are now welcome to create binary packages as you see fit.

Another impediment to binary redistribution was compiletime optimizations for CPU architecture. MPlayer now supports runtime CPU detection (specify the --enable-runtime-cpudetection option when compiling). It is disabled by default because it implies a small speed sacrifice, it is now possible to create binaries that run on different members of the Intel CPU family.

nVidia

We dislike the fact that nVidia only provides binary drivers (for use with XFree86), which are often buggy. We have had many reports on mplayer-users about problems related to these closed-source drivers and their poor quality, instability and poor user and expert support. Here is an example from the nVidia Linux Forum. Many of these problems/issues keep appearing repeatedly. We have been contacted by nVidia lately, and they said these bugs do not exist, instability is caused by bad AGP chips, and they received no reports of driver bugs (like the purple line). So if you have a problem with your nVidia card, you are advised to update the nVidia driver and/or buy a new motherboard or ask nVidia to supply open-source drivers. In any case, if you are using the nVidia binary drivers and facing driver related problems, please be aware that you will receive very little help from our side because we have little power to help in this matter.

Joe Barr

Joe Barr became infamous by writing a less than favorable MPlayer review. He found MPlayer hard to install, but then again he is not very fond of reading documentation. He also concluded that the developers were unfriendly and the documentation incomplete and insulting. You be the judge. He went on to mention MPlayer negatively in his 10 Linux predictions for 2002 In a followup review of xine he continued stirring up controversy. Ironically at the end of that article he quotes his exchange with Günter Bartsch, the original author of xine, that perfectly summarizes the whole situation:

However, he also went on to say that he was "surprised" by my column about Mplayer and thought it was unfair, reminding me that it is a free software project. "If you don't like it," Bartsch said, "you're free not to use it."

He does not reply to our mails. His editor does not reply to our mails. Here are some quotes from different people about Joe Barr, so you can form your own opinion:

Marc Rassbach has something to say about the man.

You may all remember the LinuxWorld 2000, when he claimed that Linus T said that 'FreeBSD is just a handful of programmers'. Linus said NOTHING of the sort. When Joe was called on this, his reaction was to call BSD supporters assholes and jerks.

A quote from Robert Munro on the mplayer-users mailing list:

He's interesting, but not good at avoiding, um... controversy. Joe Barr used to be one of the regulars on Will Zachmann's Canopus forum on Compuserve, years ago. He was an OS/2 advocate then (I was an OS/2 fan too).

He used to go over-the-top, flaming people, and I suspect he had some hard times, then. He's mellowed some, judging by his columns recently. Moderately subtle humor was not his mode in those earlier days, not at all.