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

[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?

[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.

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: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: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.

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).

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: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?

[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?

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.