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

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.