The problems with MPlayer

The website

Firstly, and perhaps least relevant to the software itself, is my concern about the project’s website. As anyone who has Googled for MPlayer may know, the root page on their domain contains a brief message before redirecting. This is not only self-evidently annoying and sub-standard, but it is formally denounced by the W3C! The example code for a bad site is:

and the MPlayer redirect page (wget http://www.mplayerhq.hu) contains the code:

Admittedly, not everyone, or even every web master, is familiar with W3C thinking on the issue, but given that it is the first thing visitors see, and it is an unnecessary behaviour not known almost anywhere else, it is hard to understand why they would choose to keep such a setup.

Unfortunately, once the redirect has taken place, more mistakes emerge. The default colour scheme is a mix of cream, beige and brown, and breaks many of the standard rules for web design. The text colours do not have sufficient contrast from the background, links are given an unfamiliar styling which is unique to their website, and there is no obvious distinction between visited links and unvisited links. Again, one can’t expect every person who makes a website to be an expert, but surely for a website so important, the web developer could have at least checked that they didn’t, say, make the first two mistakes of web design, or point 10 of the most violated homepage design guidelines, according to usability expert Jakob Nielsen. Of course, I am aware that the site offers other designs, but they are not the default for new visitors, nor can a user set one as default.

If the webmaster was looking for another rule to break, then they need look no further than the famous W3C markup validator which states that the main MPlayer page “Failed validation, 4 errors”. In fact, the validator goes on to explain that these are 4 instances of the same mistake, the famous “ampersands in URLs” problem, and even gives a link to a page explaining how to fix it. I could not resist, though, seeing the page’s ISO validation results from my own validator, and unsurprisingly it gives a higher number of errors: “Failed validation, 46 errors”. The key point from those results, however, is that the page, despite trying commendably, does not properly implement ISO dates, again in ignorance or apathy of the W3C advice.

Finally (in terms of the website) there is the notable lack of any news feed. Almost every modern CMS provides one automatically, and even Debian’s bespoke website system allows for a security advisory feed on the front page, and a weekly news feed. This is disappointing, and I hope that members of the project don’t expect security conscious users to make an exception for MPlayer and, rather than check a news feed, regularly visit the site for fear of a new security flaw being found in the software.

The bugs

Given MPlayer’s power, I tend to accept it’s slightly old-fashioned GUI and its bizarre crashing procedure when it is fed a corrupt or experimentally supported file. What did annoy me, however, was playing an old file one day and finding that, while it had worked perfectly with MPlayer before, it now had severe audio - video synchronisation problems. Of course, this is because I had upgraded the MPlayer package since last playing that file, and regressions are a fact of life in any software, but it seems like MPlayer could easily have caught this problem with a simple QA policy. They need only have 12 each 5 minutes video clips, one in each of the 12 most popular codecs and container formats, and it would only take an hour of scripted video watching to catch 90% of these problems before they got to users. A similar test could even be done without human intervention, running the scripts and checking the verbose command line output of the program against a known-good version. It wouldn’t even take that much programming for MPlayer to have a mode where it outputs a warning to the console if no audio has been played for 15 seconds, for example, or just when it reaches the end of an audio stream.

In attempting to solve this problem, I naturally looked at the aforementioned command line output, and the only thing which stood out was a line stating that the audio was 22050 Hz. This needn’t have caused doubling in audio rate, but my suspicion caused me to search for evidence of this hypothesis on Google. I was relieved to find a page which mentioned the same audio frequency and synchronisation MPlayer bug containing the advice of trying mencoder -speed 2 -noskip -ofps 25 to re-encode the video. This seemed extreme, however, and I certainly didn’t want to be consigned to converting every video file I downloaded, just based on a regression in MPlayer. As such, I kept looking, finally resorting to studying these mencoder options in the extensive manual, and realising that I could view the file with audio and video streams at the correct speed, without re-encoding, simply by giving MPlayer (on the command line) the options -fps 25. This was strange, and should have been unnecessary, but it was possible because of MPlayer’s policy of not degrading their software to support only the options that fit in a simple GUI.

I would have expected, at this point, to be promptly furnished with an updated version of MPlayer through my package manager, which fixed this problem and allowed me to forget about the extra command line option. This was not the case, though, as the next change I was aware of regarding audio speed was a further regression. I may not actually have upgraded between finding the first and second bugs, but I believe the two regressions may be unrelated. They admittedly were both synchronisation bugs, but the difference was that the second bug could not be fixed by adding -fps 25. So again I went to Google, this time finding the short and simple answer “try -correct-pts” in a thread about YouTube videos losing synchronisation. Sure enough, this answer worked, and I have yet to find a video this doesn’t fix, but neither has there been an official release fixing that bug in the two and a half months since that post.

The worst offence

As I have said, all software has bugs and all projects are free to prioritise their resources. After all, with Free software, people are able to fix the things they don’t like if a project has overlooked something, which is why this method of software development presents very low barriers to entry for good code and thus increases development speed. So maybe MPlayer are just following their own path, writing the code that seems most important to them, within the framework of a healthy Free software project. If that were true, perhaps I would have no grounds to complain, but consider this case: A user reports a problem to the mailing list (which is what they were intended for), they detail the settings they used to try to work around the bug, include the output of the program but even more impressively, they provide a patch which fixes the problem in the hope of helping other people. All of this is done without prompting, the user going out of their way to contribute appropriately, being above reproach. Then imagine a developer of the project replies with just a polite but short request for the patch in a different format, and the bug reporter complies. Finally, imagine that for their efforts, the volunteer is given a three sentence, sceptical reply, listing four complaints about the volunteer’s behaviour and the quality of their code. Would you ever contribute to a project like that? Would you ever contribute to any project, given that you could be treated like that?

In actual fact, the volunteer did continue to contribute, but one can’t help imagining that for every person who gets that far, there are ten who are put off from ever contributing again, or starting to contribute. If users of Free software are not allowed to complain at the work done by developers, then surely developers have no right to bluntly criticise and act ungratefully about the work of others. Whatever your view on bugs, you must find this behaviour unacceptable.

Conclusion

I have presented a lengthy case now against MPlayer, but perhaps history will be the best judge. One day the people of Europe, at least, may be able to develop software and innovate freely without the barriers to entry put up by the government-protected monopolies and cartels that use software idea patents. When this happens people will be able to choose their video formats based on their relative merits, rather than on artificial and market-distorting concerns like install-base. If that ever happens, I expect MPlayer to still be around, in some form, and better than ever.

If people patent algorithms for encoding 3D video now, will they expire by the time we have the hardware to use them?

Postscript

There may still be those who think that my criticism is invalid. About the only reason I could think of for someone trying to deny my right to free speech is that they mistakenly believe the logical fallacy that one should “earn the right” to criticise by first having contributed to the thing you are criticising. I do not hear this argument used in favour of genocide, for instance, so I am tempted to just dismiss it out of hand. However, the hacker does not win by cheating, or by destroying the good with the bad, but by unleashing a sudden, overwhelming smiting against a seemingly unassailable adversary, and proving their moral high ground by choosing to fight with one hand tied behind their back. For that reason I say “Here is my ‘right’ to criticise.” I have spent my own time not just identifying a problem with the website, but fixing it, giving to the project and the community a script that turns the MPlayer project news page into an Atom news feed. (Of course, the script is currently converting a copy of MPlayer’s page that has been altered by me, since the real one is not valid). I intend to submit this script to MPlayer and hopefully have it hosted on their site. In a future blog post I will publish the script and explain it.