MPlayer Developers Interviewed

cruocitae writes "Three of the MPlayer developers just gave an interview, talking about the "mysterious" versioning system of their software and shared a few secrets about the upcoming releases, for example some words about the long-awaited Windows GUI, and of course, DVD menus. Project integrity also was a subject.."

Comments

For Windows at least- BSplayer instead

[NeMon'ess]

I tried MPlayer a year or two ago for Windows. I'm sure it's much improved since then. I've been sticking with BSplayer though since it has so much functionality and usable skins. It has easy aspect ratio correction, low CPU usage, and key re-mapping, among it's many useful features. The key controls is what converted me from the other players I tried.

Anyone tried both more recently?

Re:For Windows at least- BSplayer instead

[NutscrapeSucks]

The programs don't really compare. BSPlayer is a front-end to Windows Media (see also MPC and ZoomPlayer). MPlayer is a reimplementation of a bunch of codecs and therefore independant of the WM infrastructure.

Re:For Windows at least- BSplayer instead

[ADRA]

On my Windows based TV computer:
Choice: Media Player Classic (MPC)
Reasoning:

1. I've never had CPU issues playing video, so I can't say that program X or program Y are more efficient.

2. Feature for feature, I've never seen any players with as many abilities as MPC. If you're leet and wanna dabble with the decoders, they let you do all kinds of thing with DirectShow. They accelerate output on DX9, The inbound codecs can be anyones. I use ffdshow, MPC, or even the official vendor codecs for things like format decoding/splitting/etc. I have the control to rewire them at my leasure if I like one over another. My experience with DVD playback is flawless.

3. Configuration is easy and straight forward for those that know how to use it. For those that don't, the default installation (with 3rd party directshow codecs installed) requires no config.

The only reservation I have with it is that sometimes I notice a cleaner picture with the powerdvd filters and I hate mapping the powerdvd filters into MPC to play it just to switch back later.

Say what you will about hating windows based technologies, but once I've tuned to my likes, it works amazingly well and I can't think of any platform media player / tech that I like more than MPC / DirectShow.

"misterious"?

[gik]

I don't even know what to say to that one.

Guys, If you want to be taken seriously, take the time to correct stupid mistakes such as this.

*Rubs eyes in disbelief*

Misterious?

[teshuvah]

Is that when its so misterious that they're is actual myst around it? You minus well knot even reed articles that our written by peeple with such bad speeling.

Re:VLC or MPlayer

[broeman]

both.

I use VLC for my IPTV-provider, because RTSP sucks in mplayer (at least for me). For the rest, I am a mplayer-fan, with support for as many codecs as possible.

Eventhough, I don't think this mainly is about VLC vs. MPlayer. Both applications uses many of the same libraries, but with different implementation. MPlayer also gets its "hands dirty" with DeCSS and WMV "support" in *nix.

When will it stop segfaulting?

[ajs]

I'm constantly running into segfaults in mplayer. I don't know if it's just a whacky codec or what, but no matter what the input, no player should ever segfault on any media. If it does, that means that memory is being handled poorly, and that's a potential opportunity for an attack vector.

Re:When will it stop segfaulting?

[Solra Bizna]

MPlayer is very sensitive to compiler version and optimization flags. Try a different compiler, or a different version of the same compiler.

-:sigma.SB

Re:When will it stop segfaulting?

[evilviper]

I'm constantly running into segfaults in mplayer.

Segfaults are very, very rare. If you are seeing one, you should report it: http://www.mplayerhq.hu/DOCS/HTML/en/bugreports.ht ml

Major problems like that, always get fixed quickly.

As I said, segfaults are very rare these days. Most of the time segfaults are reported, it's buggy hardware (hot CPU, RAM, videocard, etc.) or a known-buggy version of GCC (2.96, 3.3, etc).

Re:When will it stop segfaulting?

[ObsessiveMathsFreak]

I'm constantly running into segfaults in mplayer.

I'm not surprised. I hacked mplayer once. And I do mean hacked, not programmed.

For starters, mplayer.c is 4000 lines long. Apparently only one man really knows what's going on in there, and he's not taking a look at it. Making sense of it was beyond what my cursory overview of the code could muster. Near as I could tell most of it was written to deal with bugs.

The main developers are from eastern europe, I think. They have a pechant for three letter variables, and not a character over. Terse and unreadable code is also preferred. I remember being asked why I dond't compress a three line, readable piece of code into a once liner, line noise version. Comments have long since passed into myth. I sometimes wondered if their compilers supported them.

The mplayer system is based on plugins. Written in c code that is hacked to the limit to introduce, insofar as it is possible, object orientation into c. Void pointers abound, and are probably the most common datatype in the respository.

The main mplayer "filter chain", works backwards, with each filter pointing to the previous one in the chain. It's method completely escaped me, but it did support adding filters on the fly... sort of.

All that said, the program is fantastic. I've rarely encountered many bugs, and its abilites are amazing. I've yet to encounter a video, audio or subtitle stream it cannot handle, and mencoder can write to a multitude of formats. Once you grok the command line syntax, there is no better tool for video manipulation, period. Just don't expect to be able to make custom modifications at a moments notice.

Re:When will it stop segfaulting?

[drooling-dog]

I've seen this happen often when attempting to view WMV files, which requires the use of a Windows DLL. I think I read somewhere that the problem is specific to RedHat/Fedora, and has to do with how the DLL is loaded at runtime. Unfortunately, I can't put my hands on the source of that info at the moment (and I'm too lazy to google it; try searching "mplayer", "WMV", and "DLL").

Also, mplayer can get ornery when it can't grab as much memory as it wants. Closing an app or two usually does the trick...

Re:When will it stop segfaulting?

[jlarocco]

For starters, mplayer.c is 4000 lines long. Apparently only one man really knows what's going on in there, and he's not taking a look at it. Making sense of it was beyond what my cursory overview of the code could muster. Near as I could tell most of it was written to deal with bugs.

You've got to be kidding? I was skeptical of your post, so I looked at the mplayer source. After 10-15 minutes of looking at mplayer.c, I think I have a fairly good idea of what most of it is doing. There's a lot of stuff for portability, but it's definitly not mostly written to deal with bugs.

The main developers are from eastern europe, I think. They have a pechant for three letter variables, and not a character over. Terse and unreadable code is also preferred. I remember being asked why I dond't compress a three line, readable piece of code into a once liner, line noise version. Comments have long since passed into myth. I sometimes wondered if their compilers supported them.

Yeah, cryptic, three character variable names like "osd_show_percentage", "stream_dump_type", "too_fast_frame_cnt" and "frame_time_remaining". How cryptic! Whatever could those mean?!?

The mplayer system is based on plugins. Written in c code that is hacked to the limit to introduce, insofar as it is possible, object orientation into c. Void pointers abound, and are probably the most common datatype in the respository.

Bullshit. I just checked. mplayer.c has 3 pointers to void, and one pointer to pointer of void. A quick search through some other files found zero void pointers. The code in the loader section does have a few, but it's hardly the most common datatype.

The only part of your post that's even remotely true is "All that said, the program is fantastic." On that we agree. mplayer kicks ass.

Re:When will it stop segfaulting?

[ObsessiveMathsFreak]

I wasn't just talking about mplayer.c . There's a whole respotory in there as well. Here's a wonderful snippet I worked on. This from "vf.c"

vf_instance_t* vf_add_before_vo(vf_instance_t **vf, char *name, char **args) {
    vf_instance_t *vo, *prev = NULL, *new; // Find the last filter (should be vf_vo)
    for (vo = *vf; vo->next; vo = vo->next)
        prev = vo;

    new = vf_open_filter(vo, name, args);
    if (prev)
        prev->next = new;
    else
        *vf = new;

    return new;
}

Here's an example of the hacking in c to support OO I was talking about. Please note the void function pointers. This from "vf.h"

typedef struct vf_instance_s {
        vf_info_t* info; // funcs:
        int (*config)(struct vf_instance_s* vf,
                int width, int height, int d_width, int d_height,
        unsigned int flags, unsigned int outfmt);
        int (*control)(struct vf_instance_s* vf,
                int request, void* data);
        int (*query_format)(struct vf_instance_s* vf,
                unsigned int fmt);
        void (*get_image)(struct vf_instance_s* vf,mp_image_t *mpi);
        int (*put_image)(struct vf_instance_s* vf, mp_image_t *mpi);
        void (*start_slice)(struct vf_instance_s* vf, mp_image_t *mpi);
        void (*draw_slice)(struct vf_instance_s* vf, unsigned char** src, int* stride, int w,int h, int x, int y);
        void (*uninit)(struct vf_instance_s* vf); // caps:
        unsigned int default_caps; // used by default query_format()
        unsigned int default_reqs; // used by default config() // data:
        int w, h;
        vf_image_context_t imgctx;
        vf_format_context_t fmt;
        struct vf_instance_s* next;
        mp_image_t *dmpi;
        struct vf_priv_s* priv;
} vf_instance_t;


The codebase isn't pretty, but it does compile.

DVD Menus & XMBC

[Chris Pimlott]

Hmm... just two months ago, Xbox Media Center came out with their new DVD-player core, including menus. XBMC is built around MPlayer, I wonder if they sent some code back to the MPlayer guys for that (or perhaps vice versa)?

Re:DVD Menus & XMBC

[evilviper]

I wonder if they sent some code back to the MPlayer guys for that

No, definately not. MPlayer dvdnav was wholely written by Ötvös Attila (http://dcxx.fw.hu/)

(or perhaps vice versa)?

The dvdnav patch has been publicly available (in it's unstable form) for quite a while now. It's almost certain that the XBMC guys just grabbed the patch and applied it to their sources.

Re:Is mplayer relevant?

[Anonymous Coward]

1. I don't want to use a GUI.
2. xine doesn't play many files I try, and I don't want to figure out how to fix it.
3. mplayer plays video files on slow machines smoother than xine.

Re:Is mplayer relevant?

[grasshoppa]

I don't want to use a GUI.

Neither do I. I have xine called from my myth box, which doesn't have a keyboard.

xine doesn't play many files I try, and I don't want to figure out how to fix it.

I haven't had any problems with VOBs, MPGs, AVIs, ISOs.

mplayer plays video files on slow machines smoother than xine.

Subjective. I've had smooth dvd playback on a pIII 550 ( coppermine ).

Re:Is mplayer relevant?

[Cinder6]

In my experience, mplayer runs faster (and has mencoder). Xine always seems to desync audio and video when fast forwarding in large files, on every system I have tried it on. Also, I've never had a problem opening a file in mplayer, but I have in xine.

I'll agree that xine is better for DVDs, though!

I love MPlayer but...

[DeathPenguin]

I must admit to having skimmed over the interview. For the most part, my opinion of MPlayer as a functional piece of software has remained very high, but interest in the project has been waning. This article entitled "MPlayer: The project from hell" outlines some of the frustrations I had before I found a distro with a good package manager that could compensate for my newbie-ness. Back then, MPlayer really was superior to everything else (As far as I knew), and I've just stuck with it since. Maybe the attitude has changed by now, but MPlayer still got a black eye because manually trying to install it an exercise in frustration. Here's an example:

"Don't get me wrong. There is documentation. It is scattered, and often incomplete, and carries the same attitude I had seen elsewhere, but it is there. An example of that attitude, taken verbatim from the FAQ:

Q: I compiled MPlayer with libdvdcss/libdivxdecore support, but when I try to start it, it says: error while loading shared libraries: lib*.so.0: cannot load shared object file: No such file or directory

I checked the file and it is there in /usr/local/lib.

A: What are you doing on Linux? Can't you install a library? Why do we get these questions? It's not MPlayer specific at all! Add /usr/local/lib to /etc/ld.so.conf and run ldconfig. Or install it to /usr/lib, because if you can't solve the /usr/local problem, you are careless enough to do such things.

Perhaps instead of taking the time to flame the person asking the question, the smart aleck could have simply answered the question graciously, then spent the time saved by skipping the flames fixing bugs in the installation script."

Re:I love MPlayer but...

[Otter]

I can't find so maybe it's gone now, but MPlayer used to have a "joke FAQ" with entries like "Q: Why do I get audio but no video? A: You're blind". Unfortunately, a lot of people (myself included) mistook it for the real FAQ because a) in a Google search on "MPlayer FAQ" it came up first and b) honestly, it wasn't significantly more obnoxious or less helpful than the people in #mplayer.

Re:Is mplayer relevant?

[chrismcdirty]

But I have had problems with WMVs, ASFs, and other proprietary formats.

Re:VLC or MPlayer

[Yold]

VLC seems to be the fastest client between quicktime and mplayer on OSX. Both VLC and MPlayer were native builds too (no xdarwin). I have a slow, old 600mhz ibook, and I am able to surf the web, open apps, etc, and really never see choppy video. Especially with large video files MPlayer and Quicktime seem to bog down, I was unable to watch a 70 mb episode of Aqua Teen Hunger Force without horrible framerates on either QT or MPlayer, but VLC worked perfectly.

Xine can be used as a library

[billybob2]

Unfortunately, neither VLC nor MPlayer can be included as libraries in other multimedia applications. Having to work with an embedded instance of VLC and MPlayer is a pain and not conducive to extending functionality in object-oriented fashion.

Xine and its corresponding library Xine-lib, on the other hand, can be used as libraries inside other frontend applications such as Kaffeine and AmaroK. This allows the frontend apps to focus on what they do best: GUI, usability and eyecandy, while the multimedia-intensive parts can be neatly accessed through an API.

Is xine relevant?

[dabadab]

Why not just use mplayer and be done with it? From what I've seen, mplayer does everything that xine does, and more, so why bother.

Or am I missing something?

Re:Is xine relevant?

[dabadab]

"[MPlayer is missing] dvd menus"

Oh, I thought that was a feature.

Re:Is mplayer relevant?

[evilviper]

From what I've seen, xine does everything that mplayer does, and more, so why bother.

Xine is much slower, has a terrible interface, supports fewer audio/video codecs, takes longer to get support for newer codecs, doesn't do ANY encoding at all, doesn't support a fraction as many output audio/video devices. Doesn't have a fraction of the great video/audio filters that MPlayer does. Uses far, far more CPU-time than MPlayer. Has a god-awful interface, and no simple command-line version. Murders puppies. Doesn't include options like allowing you to output JPEGs out of every 100ths frame. Doesn't allow you to process the video, then output to yuv4mpeg for encoding with other programs. etc.

The difference between XINE and MPlayer are really the difference between Windows and Unix... Do you want a monolithic program, which can't be scripted, and has many, many restrictions imposed on it, or a small, simple tool that you can script to manipulate and modify data any way you choose?

Video on Linux

[Ponga]

Here is how I attack trying to play a video file or DVD on Linux:

First choice: VLC
Second Choice: Mplayer
Third Choice: Xine
Fourth Choice: Boot into Windoze :-(

MEncoder is fantastic

[Pedrito]

I don't use MPlayer, largely because the built-in UI (or lack thereof) makes it a pain to deal with. There are front-ends for it, but it's just not worth the trouble.

MEncoder, on the other hand is amazingly powerful. It's also a pain in the butt to use. I also have to say, the support, at least on the MEncoder forum is very lacking. When I first started using it, I was largely derided for not knowing all about video encoding to begin with and got more than one RTFM response.

The documentation is extensive, but the organization could definitely use some work and a few more real world examples would be helpful.

That said, after a month or so of struggling with it, I am pretty competent with it now and have yet to find a situation where it can't do what I want it to do. Convert from one format to another, resync video, make DVD compatible MPEGS (though it doesn't compose DVDs), etc. It's got a variet of filters, including I think 4 just for de-interlacing (I do a lot of TV captures to raw MPEG that need to be converted to AVI).

So the program itself is excellent. The support however, could definitely use some work. If you want to see some newbie bashing, the mencoder mailing list definitely a good place to hang out.

What is happening to the Mac OS X port?

[kgp]

From TFA:

Me: What do you think, how much percent of the users use the Windows, FreeBSD and other ports?

Diego: The Windows port will probably get popular once we commit the Windows GUI, which should happen soon; already some people seem to use the command line version on Windows. MPlayer OS X is popular as well.

I use MPlayer all the time on Mac OS X.

The problem is seeing any visible progress on this port. Or even fixing major bugs and releasing a build.

The current release is the MPlayer-dev-CVS-050904.dmg (i.e. September 4th 2005). This release had a massive bug that rendered the playlist an unusable -- you could add items to it. And the menu bar was not being hidden in full screen mode on the default video renderer. I'd label both of these showstoppers (breaks major functionality) and would expect a fix. It's now 8 months later and not even a dev CVS build.

So I continue to the use the MPlayer-dev-CVS-050724.dmg version.

I've never been able to find nightly builds of the Mac OS X port, either. Not through lack of trying but maybe I missed something.

Is any active development taking place on the Mac version?

Re:What is happening to the Mac OS X port?

[evilviper]

It's now 8 months later and not even a dev CVS build.

There was a major hardware failure, which took down the main server for several months. Development has continued on CVS, and you can grab a snapshot any time you wish. This hasn't just stopped OS X development. If you were a bit more observant, you'd see there haven't been new releases on the server for ANY architecture for nearly a year.

There are at least 2 MPlayer devs with PPC/OS X machines, who continue to find and fix bugs. I'm sure you'll see new OS X releases soon.

Viva La MPlayer!

[miyako]

I've played with a number of various multimedia applications, and I always come back to mplayer. Personally, I use KMplayer when I want a GUI, since it has a few nice features that GMplayer doesn't (drag and drop playlist, maintains the correct aspect ratio of the file when resizing, nicer integration with KDE). I still occasionally use Ogle for DVDs, but I'm eagerly anticipating MPlayer supporting DVD menus.
For those of you who might have stuck with Xine based players and haven't played around much with MPlayer, there are a few reasons I really like it:
The largest reason is that it plays bloody everything. I've personally never come across a file that I couldn't open with MPlayer. The worst I've ever run into is in some files that are slightly corrupted I've had to use the -idx flag to reindex the file so that I can gracefully skip over bad sections of the file instead of the video just stopping playing. I find this particularly handy when I'm downloading television shows off bittorrent and the seeders all go away when I'm at like 90%.
Mplayer also seems more lightweight ot me than Xine. Most of the time, if I'm watching video at my computer, it's because I'm doing something that's taking long enough that I'm sitting at the desk waiting for it to finish (compiling a lot of software, doing 3D rendering, etc.) so it's nice to be able to dedicate more cycles to whatever real work is getting done while still being able to relax with a video.

You are talking about two issues.

[Ayanami Rei]

BSPlayer does not link or bundle in a full ffdshow library. It can leverage the ffdshow DirectShow filter to play a lot of media types without using other WM/DS libraries (people often prefer the features of ffdshow in MPEG2/MPEG4 over filters bundled with DVD drives and/or DivX). Usually you find BSPlayer and FFDShow bundled together, for example, in the KLite Codec Pack.

However, BSPlayer is a much better parser of video container formats (ASF, WMV, AVI, OGM) and MPEG transport streams than most other players out there (maybe with the exception of VLC). All of them are better than any versions Windows Media Player. :-/

So it can handle broken, badly indexed, or partially downloaded files with ease.
Additionally, like VLC, mplayer and MPC, it can handle extended features in video containers that many other players (Windows Media Player included) omit. For example, multiple video streams, subtitles, multiple audio tracks, etc.

Re:Is mplayer relevant?

[evilviper]

Under what circumstances?

Under absolutely ALL circumstances. MPlayer has been heavily optimized for speed, while XINE hasn't. I've never before seen ANYONE claim Xine was EVER faster.

If you're actually seeing something like that, and not just trolling, either you got a poorly made binary package, or you were doing something like using the wrong output method for your system.

Some defective AVIs and VOBs I played on Xine, but made MPlayer hang.

Also something I have NEVER heard from ANYONE, ANYWHERE. MPlayer is much more tolerant of errors, and will play far more media types. If you're seeing some bug, you should report it, and perhaps provide a sample.

XVideo and ALSA is all you need. ;-) No seriously, for most users, this should not be an issue.

vidix is faster than XV in just about all cases. gl is faster if your drivers have OpenGL support, and MUCH, MUCH, MUCH faster on HD material.

svga/fbdev support makes it possible to play videos even without X11 installed, and can be faster in some cases.

> Doesn't have a fraction of the great video/audio filters that MPlayer does.

see MEncoder comment.

No, I'm not just talking about encoding. Good inverse telecine filters are absolutely necessary in the US and other NTSC countries. There are plenty of other filters like overlays for interactive on-screen graphic interfaces (eg. Freevo), filters to fix videos which have been improperly encoded, like deinterlacing telecined content, numerous postprocessing filters, filters to remove TV station logos, etc.

Mplayer works great on low end computers

[kfazz]

I used to run mplayer on an old PII 450Mhz dell latitude with 64MB of ram under windows 2000 using direct rendering and framedropping i could watch 640x480 XVIDs (~150mb per file) at very reasonablle levels of quality. And I wasn't even using the winvidix thing for video accelleration on account of it not supporting the neomagic chipset. trying to play these same files in WMP was akin to watching a slideshow with the "next slide" guy passed out in his chair. winamp with ffdshow worked much better than WMP, but mplayer still beat it.