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

MISTERIOUS

[dhakbar]

Wow. The world is full of mistery.

This whole thing is a mystery.

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

[epiphani]

I'm big on Media Player Classic on windows. Small, lightweight, and generally handles just about everything. There are a few codec packs out there that are required to do some things, but its generally ok.

BSplayer annoyed me when I first tried it, but then again it also kinda struck me as spyware the first time around. My mistake.

Re:For Windows at least- BSplayer instead

[pavon]

I love VLC. I use it mainly on my Mac, but have also run it in Linux and Windows. The interface is very clean and straight forward, and it has played every file I have thrown at it. The only problem I have had with it is reading DVDs from the drive (if I copy the files to disk it seem to work fine). Don't know if this is specific to the Mac.

Re:For Windows at least- BSplayer instead

[zakezuke]

It (BSplayer) 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.

While mplayer does have the ability for key remaping, one thing it lacks over winamp is that nice 3rd mouse scroll feature. Default scroll wheel is volume, 3rd button and scroll is jump forward and back. Mplayer is nice but i've not managed to figure out how to define anything beyond mouse buttons. While I do have a wireless keyboard, I find the wireless trackball infaninatly more handy. I "could" buy a wireless numeric keypad, but i'm cheap and prefer to use what I got.

Re:For Windows at least- BSplayer instead

[Shark]

Well, both mplayer and VLC support keymapping. You'll find VLC's interface to mapping keys a tad easier though.

Re:For Windows at least- BSplayer instead

[Low2000]

I'm a bit wary of BSplayer since it contains WhenU spyware.

Is there a version without I can try?

Re:For Windows at least- BSplayer instead

[evilviper]

It has easy aspect ratio correction, low CPU usage, and key re-mapping, among it's many useful features.

MPlayer has lower CPU usage than any other video player I've ever tried on Windows. It really uses around half the CPU time to play videos as something like MPC does. Frankly, I really don't understand how Windows can be so terrible at multimedia, and why people aren't more upset about something like DVD playback using 50% of their multi-GHz CPU.

As for usability, there are several 3rd party MPlayer GUIs for Windows which make it rather easy to operate.

MPlayer supports arbitrary key remaping beyond any other player out there. You can bind any key to any of ~100 functions the player can perform. You can arbitrarily define how far you want it to seek forward/backward with each key, etc. You can bind a key to change the aspect on-the-fly if you want.

Re:For Windows at least- BSplayer instead

[NeMon'ess]

Dang it. The free version does come with adware now, but only since February 16th. I haven't upgraded since November (version 1.36) so I was unaware.

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.

Re:For Windows at least- BSplayer instead

[NeMon'ess]

Can you elaborate? I've had files that Windows Media Player 9 and Classic (version 6.4) could not open, but BSplayer could. Some files WMP9 could not seek through the files because of a damaged keyframe index, but BSplayer could. Currently, some filetypes are rendered with ffdshow, and other with divx 6 or xvid. BSplayer is how I control the playback though and resize, or swap audio streams.

Re:For Windows at least- BSplayer instead

[drinkypoo]

Frankly, I really don't understand how Windows can be so terrible at multimedia, and why people aren't more upset about something like DVD playback using 50% of their multi-GHz CPU.

Playing back a DVD uses less than 1/3 of my Athlon XP 2500+ using PowerDVD 5 (no, I don't have the fancy subpixel video scaler turned on, I have a CRT.)

Re:For Windows at least- BSplayer instead

[NeMon'ess]

I'm not familiar with Filehippo, but they have version 1.37 which was the last one before February's version with adware. They even note on the page that later versions have the adware and so will not be hosted by them. Sounds like a good site.

I checked out what WhenU does. According to what I read, it downloads a bunch of ads from their server, and then the program running on the user's machine decides what ads are appropriate to display. It apparently does not send browsing info back to the central server. So it's more like if your TV downloaded all the ads from a show, then only displayed the ones it thought you would be interested in.

Re:For Windows at least- BSplayer instead

[evilviper]

Playing back a DVD uses less than 1/3 of my Athlon XP 2500+ using PowerDVD 5

And playing back a DVD averages less than 5% of my Athlon XP 2000+ using MPlayer.

Re:For Windows at least- BSplayer instead

[Cyberax]

Try LightAlloy: http://www.softella.com/index.en.htm - you'd like it.

Re:For Windows at least- BSplayer instead

[baadger]

Try compiling your player with XvMC (both MPlayer and xine-lib support it). I'm unsure to what extent it might be worth a shot.

Re:For Windows at least- BSplayer instead

[nogginthenog]

Not tried it, but looking at the screenshots I can see 2 bad points:
- It's not free (MPC is)
- It's skinable! (yes, skinable = bad!)

"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*

Re:"misterious"?

[Chris Pimlott]

From the number of mispellings and awkward phrasings, I'm guessing this article was written by a non-native English speaker.

Re:"misterious"?

[Golias]

I'm guessing this article was written by a non-native English speaker.

And edited by somebody with a third-grade education and no access to basic spell-check software.

Spell Check?

[metaomni]

I mean, that one is just terrible. It's "mysterious".

Re:Spell Check?

[LiquidCoooled]

What are you on about, I think its Brillant!

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

[giorgiofr]

Bull. If they are not able to layout their thoughts decently in another language, they should a. refrain from posting crap on /. and use a localized portal to discuss (I'm sure there is a /. in my native language, another one in Spanish, one in Japanese...) or b. study some more. Not being a native speaker is not an excuse for (piss-)poor spelling, when nobody's forcing you to post to the front page.
And yes, I do speak more than a language. That's *precisely* the reason why I am allowed to make such comments.

Re:Misterious?

[drinkypoo]

You know, I don't speak spanish (well... muy poquito) but if I were posting something to a spanish site I'd be sure to find a fluent speaker that would be willing to do translation/proofing for me. And, before you ask, I would expect people to expect me to learn the native language of any country I moved to, and I would do my best to do so, because I think it's a reasonable expectation.

Re:Misterious?

[tetabiate]

According to my experience by living in various european and american countries, to speak a language fluently it is seen as a matter of national pride and constitutes the ultimate recourse in situations where some people feel surpassed by the personal and/or professional skills of a foreign person. From the psychological point of view, such a reaction is completely normal (healthy), otherwise they should confront depression.

Is mplayer relevant?

[grasshoppa]

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

Or am I missing something?

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!

Re:Is mplayer relevant?

[chrismcdirty]

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

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:Is mplayer relevant?

[caseih]

Maybe things have changed recently, but I always found mplayer to quickly lose video/audio syncing and often segfaults, although I disovered that the segfaulting is because of the video output device somehow. Using gmplayer works fine. But xine just works better for me. I run it from the command line (Gui hidden) and it plays everything I throw at it.

Re:Is mplayer relevant?

[diegocgteleline.es]

"monolithic" is what makes mplayer feel to me. It's just me? Lots of options, yes, really versatile, but....

Don't get me wrong. I've zero idea about mplayer internals, but I wonder why ej: mplayer is a big binary monolith instead of something more modular which can be used by other people.

Xine may not be perfect, but I've seen people reusing xine in other places: enlightenment 17, for one. Or totem-xine which has, BTW, a firefox plugin to allow people see videos with a gui to handle videos, something that linux desktop has been missing for years (and don't even mention the useful but ugly hack that mozplugger is, please). Not to mention that it's used by nautilus to do things like ej: generate thumbnails. Mplayer may be a good video player, but xine is a *useful* video player.

Re:Is mplayer relevant?

[Orrin Bloquy]

Murders puppies.

Now if that isn't a Frist Post, I don't know what is.

Re:Is mplayer relevant?

[Saint Stephen]

I love command line mplayer, for videos, music, everything. I get all the eyecandy I want and it's scriptable with perl or sed or whatever. I use rl (randomize lines) to shuffle my music, and some hacky scripts to keep track of things and only play things once.

Re:Is mplayer relevant?

[Maru Dubshinki]

What's wrong with the mozilla-mplayer package/plugin? Works fine on Debian for me.

Re:Is mplayer relevant?

[evilviper]

why ej: mplayer is a big binary monolith instead of something more modular which can be used by other people.

Speed, speed, and more speed...

Using external libraries incures a performance penalty, so the default is to compile everything static. You can use external versions of most libs if you specify them during configure.

If you want a library, use libavcodec. If you want to use MPlayer, that's exactly what "Slave Mode" is for.

Personally, I love the binary monolith, if only because it keeps me from having to deal with dependency hell...

(and don't even mention the useful but ugly hack that mozplugger is, please).

Okay, I'll mention mplayerplugin then.

Or better yet, something like kmenc15 (http://kmenc15.sourceforge.net/).

Or how about Freevo, or XMMS-MPlayer, or GImageView, or anything else on the Projects page: http://mplayerhq.hu/homepage/design7/projects.html

Re:Is mplayer relevant?

[Cal Paterson]

You're confusing what monolithic means, I think. I wouldn't call mplayer monolithic in particular; it's not (it's not especially modular either). You have the option of compiling the whole thing as a static, but that's not default (or even that well used). MPlayer doesn't interact with anything much other than input, codec and output; it's not of the structural complexity where it can really be either monolitic or modular. I haven't used Xine in depth, but I expect it's pretty much the same (I suspect the grandparent meant something other than exactly what you were construing him to mean).

I think the distinction he's trying to draw is that MPlayer really is a command line tool; the people who use MPlayer aren't really going to be the same crowd that use things like nautilus or totem. Normally you only get mplayer plugins where people see them are really critical; mplayerplug-in for example. If you're using IceWM or *box pretty much just to get graphical web browsing and multiple terms (like I am), then totem and nautilus etc seem redundant.

I can't speak for xine, but MPlayer is a reasonable example of a good "Unix" program; at least according to the Unix Philosophy.

Re:Is mplayer relevant?

[instagib]

Informative? For Mplayer fans perhaps, sorry. But for those still enjoying movies with Xine, you may want to know:

> Xine is much slower

Under what circumstances? On my PIII-500 (which I regularily use since 3 years to watch DVDs over a beamer), Xine is the only player which stays below 75% load for VOBs. MPlayer hits 100% on scenes with lots of motion, and skips (and corresponding "your system sucks" messages are displayed).

> has a terrible interface

That's your opinion/taste. IMHO, it's OK with the right skin.

> , supports fewer audio/video codecs
> , takes longer to get support for newer codecs,

Some defective AVIs and VOBs I played on Xine, but made MPlayer hang. I always use MPlayer first to look at a movie I come across (because it starts faster, which is an advantage for MPlayer), but when MPlayer hangs, Xine normally plays it.

So MPlayer surely is more cutting edge, but less forgiving with common file types.

> doesn't do ANY encoding at all,

Why should it? It's a player. Comparing Xine with MPlayer makes sense, but not comparing it with MEncoder. MEncoder is great, though. I encode with MEncoder, I watch with Xine.

> doesn't support a fraction as many output audio/video devices.

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

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

see MEncoder comment.

> Uses far, far more CPU-time than MPlayer.

You said that before, but still is not true (see above).

> Has a god-awful interface,

You said that before, but is still only your opinion/taste.

> and no simple command-line version.

No, the xine command line options are few and simple. MPlayer instead has hundreds of options, and is complex and as complete as possible.

As a summary: Xine is perfect for watching common video files and DVDs (from disc or ripped). MPlayer comes in when you need to tinker with video/audio processing, or if you have strange formats and/or output hardware.

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.

Re:Is mplayer relevant?

[kv9]

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

is xine relevant? why not just use mplayer and be done with it? from what everyone knows as a fact (not just what i've seen), mplayer does everything that xine does, and more (like works properly on windows since forever, plays *everything*, comes with an awesome encoder), so why bother?

i really love these type of questions. nobody is forcing you to use mplayer. if you love xine that much then use it happily and stop belittling other players (especially the ones that exceed it in functionality, such as this case).

Re:Is mplayer relevant?

[instagib]

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

It's my experience, since many versions during the last three years of MPlayer and Xine.

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

Output method was always XV for both (and ALSA for both as well). I compiled the releases always myself, on the same Linux system, Xine without any configure options, and MPlayer always with "--enable-gui --enable-largefiles --disable-lirc --disable-lircc --enable-menu --disable-arts --disable-esd --disable-dvb --disable-dvbhead".

I just used some 720x480 VOB on my system: MPlayer averages at 80%, Xine at 55%.
Maybe me system is strange, but I doubt it.

But nevermind. The only reason I wrote this is to point out that for some, Xine is not so bad as you say.

Re:Is mplayer relevant?

[gnud]

Ok, then let me add my voice to the fray :) I used to watch all videos with mplayer, but since it crashed so much, I "converted" to xine. Simple as that. I'll admit, though, that mplayer is probably faster.

Re:Is mplayer relevant?

[evilviper]

It's my experience, since many versions during the last three years of MPlayer and Xine.

Yes, well... Either something is very wrong with your system, you're completely mistaken, or you're just making things up. I find the latter to be most likely.

Posting at +1, UID of almost 900,000, no details or info to back-up your extremely vague claims that fly in the face of all logic.

If you've got files that crash MPlayer and not Xine, upload a sample somewhere so it can be verified.

If MPlayer is insanely slow for some reason, perform some detailed benchmarks with both programs on the same videos, and post the full output somewhere as well. You can send it to the mplayer mailing list as well.

Re:Is mplayer relevant?

[baadger]

Unfortunately any browser plugins for video on Linux AMD64 are spotty at best. Even using a 32-bit browser (firefox-bin) I find myself hacking my way through HTML to find the video file, download it manually and opening in mplayer.

the mplayer-plugin works to a degree, but is hopelessly unreliable.

Re:Is mplayer relevant?

[Hydroksyde]

is xine relevant? why not just use mplayer and be done with it? from what everyone knows as a fact (not just what i've seen), mplayer does everything that xine does, and more (like works properly on windows since forever, plays *everything*, comes with an awesome encoder), so why bother?

i really love these type of questions. nobody is forcing you to use mplayer. if you love xine that much then use it happily and stop belittling other players (especially the ones that exceed it in functionality, such as this case).

Today's lesson, children, is on the subject of Irony.

Re:Is mplayer relevant?

[kv9]

Today's lesson, children, is on the subject of Irony.

today's word: "sarchasm: the gulf between the author of sarcastic wit and the person who doesn't get it"

you gotta love irony. it's so... ironic.

Re:Is mplayer relevant?

[kdekorte]

Have you ever submitted a bug to the mplayerplug-in project about a website that does not work? Perhaps I could fix the problem.

Re:Is mplayer relevant?

[HaydnH]

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

How lazy of you! FYI: all you need to do is download the codecs and place them in /usr/lib/win32!!

Re:Is mplayer relevant?

[HaydnH]

How on earth was the parent not modded either flamebait or troll?? +5 informative? +5 infactual more like!!

Re:Is mplayer relevant?

[baadger]

It's not the mplayerplug-in's fault specifically. Alot of the issues are with 32bit only proprietary codecs and getting 32bit builds out there that actually work with firefox-bin, mozilla-bin or opera.

Atm plugins are being recognised fine according to "about:plugins" but simply do not load on websites, go into stop mode, and don't issue any errors in the terminal.

Re:Is mplayer relevant?

[kdekorte]

With a 64bit firefox 64 bit plugins are needed. However, since mplayerplug-in does not load mplayer (it forks it). mplayer can be a 32bit binary and can use the 32bit dlls. What could be a problem is that mplayer is being passed a 64bit window id and mplayer doesn't know what to do with it. So using 32bit browser, 32bit plugins and a 32bit mplayer is your best option.

Re:Is mplayer relevant?

[Dog-Cow]

"Posting at +1, UID of almost 900,000..."

You have just invalidated anything you might ever say in any forum anywhere. You are stuck-up snob to beat all snobs.

WHAT THE FUCK DOES SOME STUPID SLASHDOT UID HAVE TO DO WITH THE VERACITY OF ANYTHING?

Fucked-up people like you have turned /. into a cesspit.

Re:Is mplayer relevant?

[evilviper]

Maybe because everything I've said is factually correct, and you're just trolling for Xine...

Feel free to try and dispute any of the facts above, rather than just bitching and whining.

Re:Is mplayer relevant?

[evilviper]

WHAT THE FUCK DOES SOME STUPID SLASHDOT UID HAVE TO DO WITH THE VERACITY OF ANYTHING?

If he had posted any evidence to back-up his claims, it wouldn't have mattered at all.

However, in the case of bald-faced assertions that go against all logic, with no evidence, the UID and lack of karma bonus will usually tell you whether or not you're just seeing some 13 year old who doesn't know what he's talking about, some troll with a nice new account, etc.

Fucked-up people like you have turned /. into a cesspit.

Looking through your comment history, it looks like you might actually hold that distinction.

Re:Is mplayer relevant?

[evilviper]

Is it so hard for you to believe that different people can have different experiences on different hardware setups?

Yes. It makes absolutely no sense at all that MPlayer, which has been heavily optimized with hand-written assembler in speed-critical places (including imported libraries) would be slower than Xine, which has not recieved much performance tuning, and certainly doesn't have the hand-optimized code that MPlayer does.

Extrodinary claims require extrodinary proof. I'll believe it when I see someone provide detailed benchmarks with both, a copy of the sample used, and plenty of system info. It's not hard, but nobody is doing it... Presumably because they can't.

Besides that, I have no reason to trust these posts. Almost NOBODY is even posting as a logged-in user, so this could just as well be one idiot masquerading as several for all I know. None of which are spending a minute to provide real evidence.

Re:Is mplayer relevant?

[HaydnH]

Perhaps you should read the other ~40 posts with the facts - I didn't wan't to make a redundant post. As an example though, Xine uses the same codecs as mplayer, in fact you download them from the mplayer site! So stating that it supports less file formats is ludicrous!

Re:Is mplayer relevant?

[evilviper]

As an example though, Xine uses the same codecs as mplayer, in fact you download them from the mplayer site! So stating that it supports less file formats is ludicrous!

Absolutely wrong. You have no idea what you are talking about.

First off, the "essential" codecs xine has you download are only a fraction of the codecs available in the "all" packages (you want both the Linux and Win32 ones), and I sincerely doubt Xine supports all of those avalilable. They tend to focus their efforts on the most popular, and neglect all the less common formats.

In addition, even if it did support all the binary DLLs, those are only a fraction of the codecs MPlayer supports. These include: qtx x264 xvid libavcodec real dshow/dmo win32 faad2 libmpeg2 liba52 mp3lib libtheora tremor libmad gif opendivx libdv amr_wb amr_nb xanim faac musepack libdts speex twolame toolame liblzo. And those are only the offical ones. There are a few patches floating around for other odd codecs as well.

In addition to all of this, it's not just a question of having the codecs working. In order to make any use of them, you have to be able to decode the container to read out the streams. New Quicktime/MOV atoms spring up rather frequently, and it's the MPlayer devs that figure out how to decode them, and presumably with the xine guys checking out the code somewhat later and integrating those new features into their player. I very rarely see the opposite. This usually is the big issue with new formats not working, particularly when they use codecs that are otherwise supported.

So stating that it supports less file formats is ludicrous!

Acting like you know what you're talking about is ludicrous!

Xine developers will tell you that Xine is based on a large ammount of MPlayer/ffmpeg code, and that they continue to pull updates and fixes from MPlayer.

Re:Is mplayer relevant?

[HaydnH]

First off, the "essential" codecs xine has you download are only a fraction of the codecs available in the "all" packages

Xine does support the "all" package of codecs - I use it!

In addition, even if it did support all the binary DLLs, those are only a fraction of the codecs MPlayer supports. These include: qtx x264 xvid libavcodec real dshow/dmo win32 faad2 libmpeg2 liba52 mp3lib libtheora tremor libmad gif opendivx libdv amr_wb amr_nb xanim faac musepack libdts speex twolame toolame liblzo.

Try doing some research before posting... you even mention codec's which are supported by ffmpeg (e.g: libavcodec).

Re:Is mplayer relevant?

[evilviper]

Xine does support the "all" package of codecs - I use it!

Now you're just taking things out of context. I said (in the next sentence):

I sincerely doubt Xine supports all of those avalilable.

So, unless you've tested EVERY DLL in there, you're not proving anything.

Try doing some research before posting...

You've clearly misunderstood. I wasn't saying Xine didn't support those codecs, just providing a list you could use for comparison. I'm not about to spend an hour of research on every idiotic claim someone makes on /.

you even mention codec's which are supported by ffmpeg (e.g: libavcodec).

Umm, what? If you're trying to say that libavcodec is from the ffmpeg project, I know that quite well. MPlayer and ffmpeg are largely one-in-the-same, sharing servers and developers. In fact devs for either project have commit access to the other, by default, and most use it.

If you're trying so say something else, I completely missed it.

Re:Is mplayer relevant?

[caseih]

uh huh. Slow CPU eh. Let's see. It's an Athlon 2800+ XP running at 2 GHz. While that may not be as fast as a CoreSingle at the same speed, it's more than enough to decode video. I mean come on. xine has absolutely no problems with syncing or frame dropping for that matter. No this is an mplayer problem (a chronic problem I might add). Still mplayer is a marvelous piece of work, being the first to use windows dlls to decode proprietary codecs. Until the situation improves, though, xine just works fine for me. I'll check out mplayer from time to time and see how it is progressing.

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?

[Jerf]

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.

While that is certainly literally true, it's worth pointing out that codecs are bits of code that are pushed hardest to extract every bit of performance out of them. Such hyper-optimization tends to result in other qualities of the code taking longer to catch up when compared to a more normal type of program, such as "stability" and "readability".

Is that bad? Yeah, sure, whynot. Is there a way around it? Probably not; because of the desire for performance the codecs are often flying without a net, including significant chunks of assembler. Changing a codec to, say, Python would cut out the segfaults, but would cost a lot of performance; I'll pull a number out of my ass and call it at least 1000x slower.

You can't have it all.

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?

[IgLou]

Well from what they say in the article it must be a problem with your system because...

"our releases are not even beta, they are perfectly stable"

Someone get these guys in marketing, that's where they should really be! Either that or it might remotely be possible that they have a different understanding of the term stable compared to others.

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?

[evilviper]

Terse and unreadable code is also preferred.

No, actually FAST code is preferred to READABLE code.

There's good reason why, when you hear stories about people watching DVDs on their 133MHz systems, they're always using MPlayer...

MPlayer plays MPEG-1/2/4 videos at 720x480 on my 1.6GHz system using LESS THAN 1% CPU TIME. I can play back 1080 videos on this system in realtime with any codec around (h.264 drops a few frames, but that's all).

Re:When will it stop segfaulting?

[boschs_haywain]

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.

[caveat]I use a fairly ancient checkout of mplayer cvs[/caveat] just about every day and the only codec I've run into trouble with was on a DVD with big-endian AC3 audio streams.

mplayer rocks.

Barton

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?

[baadger]

%MPlayer plays MPEG-1/2/4 videos at 720x480 on my 1.6GHz system using LESS THAN 1% CPU TIME.

I'm using an AMD64 3500 and mplayer chugs away 5-10% cpu (as measured by top) with a significant ~5% CPU usage increase in X, a total CPU usage of 5-11% at anyone moment throughout the movie in front of me. (I suppose a better way to benchmark it would be to play the whole 90 minute movie and then checkout the cpu time utilised by the end but i'm throwing ballparks here). I'm also playing PAL which doesn't require any funky inverse telecine or deinterlacing most of the time, so logically NTSC movies (720x480) would require more CPU time.

The CPU utilisation of mplayer is great but it's not 1% great.

Re:When will it stop segfaulting?

[evilviper]

I'm using an AMD64 3500 and mplayer chugs away 5-10% cpu (as measured by top) with a significant ~5% CPU usage increase in X, a total CPU usage of 5-11% at anyone moment throughout the movie in front of me.

From the increase in X CPU usage, it sounds like you're perhaps using a junky on-board videochip (or perhaps something with lowsy drivers), or using an output method like x11 instead of one of the many overlay outputs (which hardly even involve X). I'm just using an ultra-cheap, 4 year-old GeForce4 AGP card myself.

Since you're on an AMD64, I wonder if you've compiled it as a 64-bit or a 32-bit binary; if you compiled it yourself or are you using a binary package (runtime CPU-detection blows)? What version of GCC did you use, which version of MPlayer, which kernel version, etc.

Certainly the AMD64 version of MPlayer hasn't gotten nearly as much hand-written assembler optimization as the standard x86 version has, but your performance should still be better...

I'm also playing PAL which doesn't require any funky inverse telecine or deinterlacing most of the time, so logically NTSC movies (720x480) would require more CPU time.

You're assuming inverse telecine and deinterlacing is CPU-intensive. It can be, with filters like pullup and kerndeint, but most of them, like filmdint, use practically no CPU time at all. So the larger resolution of PAL material may be more of a slowdown than inverse telecine or deinterlacing.

The CPU utilisation of mplayer is great but it's not 1% great.

The fact that you aren't getting it, doesn't mean it's not true. I can think of many reasons your CPU usage would be higher than it should be...

Perhaps you're using a large cache value, while -nocache is actually fastest. Perhaps -rtc support is causing a slowdown, and you can use -nortc for a speed-up. Options like "-lavdopts fast" work nicely in most cases as well.

Re:When will it stop segfaulting?

[greylion3]

Did you two look at the same version of the code?

Re:When will it stop segfaulting?

[ookaze]

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

Perhaps that's the reason, and perhaps you just still are using the release from nearly one year ago (pre7), and not a CVS version.

Re:When will it stop segfaulting?

[renoX]

As those two opinion were so wildly different, I had a look at their CVS archive: to summarize: jlarocco is right, please mod him up (or mod the GP down as troll as he deserves it, lying).

mplayer.c is quite readable with good names for variables,I didn't notice abuse of void* nor unreadable code.

The only bad parts is that the main function is huge and the file itself is big, but this is not the disaster the GP said.
Diclaimer: I've only looked to mplayer.c not the other files.

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.

Re:When will it stop segfaulting?

[ajs]

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

About half of the time that I hit "stop" and close the player on a valid AVI, it seg faults. If I try to play corrupted AVI files (which it should choke on), it seg faults (which it should not do, as that indicates a failure in bounds checking that could be very dangerous if viewing untrusted content). These are common behaviors on multiple machines, one of which is brand new. I've used FC3, FC4 and FC5 without a change in behavior and I have never compiled a custom version of the player (I've used the Fedora and/or FreshRPMS versions only), and are thus compiled with fairly modern compiler versions (circa the distribution release + updates) and I update on a frequent basis from updates, extras, freshrpms and, where applicable, legacy.

I'm a fairly routine user doing fairly routine things, and a dialog with a "signal 11" error is routine for me. What are the developers doing differently that seg faults are so rare for them? Are they only using carefully crafted test files? Are they running with some special libraries or compiler versions? Is there an unreleased fix?

Re:When will it stop segfaulting?

[evilviper]

About half of the time that I hit "stop" and close the player on a valid AVI, it seg faults.

MPlayer doesn't have a "stop". Perhaps you're talking about gmplayer or some other front-end?

If I try to play corrupted AVI files (which it should choke on), it seg faults (which it should not do, as that indicates a failure in bounds checking that could be very dangerous if viewing untrusted content).

Nobody in their right mind would have MPlayer running as root, so it's not a huge risk. Certainly, yours is a bug nobody else is seeing these days.

(I've used the Fedora and/or FreshRPMS versions only), and are thus compiled with fairly modern compiler versions

"fairly modern" doesn't mean anything. gcc 2.96 was "fairly modern" at one time. gcc 3.3 is fairly modern too, yet buggy as hell.

Also, unofficial packages have been known to have numerous problems in the past. Try the official RPMs on the website, if you don't want to compile anything.

What are the developers doing differently that seg faults are so rare for them?

Using official versions. Compiling from source themselves. Using the latest versions of the program. Not using gmplayer or any other front-end. etc.

Are they only using carefully crafted test files?

No, definately not. MPlayer has an ftp directory just for people to upload problematic files.

Are they running with some special libraries or compiler versions?

No, although avoiding libraries and compiliers with custom distro "fixes" will certainly help a lot. I know, first hand" RedHat has a history of really buggy software in their releases, libraries and compilers. gcc 2.96 was a RedHat-only phenomenon, which was derided by most of the free software world.

Is there an unreleased fix?

Quite a few in CVS, since there hasn't been an actual release since 1.0pre7 about a year ago.

Re:When will it stop segfaulting?

[ajs]

You keep harping on things like gcc 2.96... You do realize that that was released NINE releases ago for what is, in name, and in practice, a completely different product, right?

What's more, if you go back and look at the history, the Red Hat team had a lot of problems with the release of 2.96 (which was a Red Hat (well, really, Cygnus) pre-release of the compiler version that they (along with the community) had been developing for several years under the previous name egcs... 2.96 was the re-merging of 2.x and egcs into 3.0, a once-again-standards-compliant C and C++ compiler suite). The thing was, everyone else proceded to have the exact same problems a few months later when gcc 3.0 was officially released. There WERE some compiler bugs in 7.0's gcc 2.96, but they were minor and fixed quickly. The REAL PROBLEM was that gcc 2.96 and thus gcc 3.0 enforced standards that gcc 2.x had always been lax about, and thus many programs needed small fixes in order to compile correctly. Everyone took this as "Red Hat enforcing their world view" until gcc 3.0 came out and everyone found out that it was the entire gcc community enforcing the standards.

2.96 was the only stable compiler for Sparc, Alpha and MIPS under Linux at the time. 2.96 was not an option for that reason, and Red Hat had a scheduled release date to make. They were in a tight spot, and they made, IMHO, the right call. The soon released minor releases of 7.1, 7.2 and 7.3 brought much improved versions of the compiler suite and 2.96 is STILL used in many production environments because of its massive improvements in the implementation of C++ without the later experimental features of the 3.1+ releases. The folks at Cygnus took a huge beating for what was ultimately a very well managed release that caused only minor headaches in reality, and they revitalized the gcc project which had stagnated pre-egcs, due to the political tensions between the C and C++ as well as the Intel and non-Intel worlds.

So, if you're going to tell a user that their problems aren't problems, but rather stupid platform issues that the player can't possibly do anything but seg fault on, you might want to talk about the current day and modern compiler releases, or at least not parrot the bad mythology of a few who have an axe to grind against a company that has done more for open source than any 100 of the axe grinders in question.

Re:When will it stop segfaulting?

[ajs]

There's a typo in my post. There's a bit that should read "2.<96 was not an option", but my < got eaten.

Re:When will it stop segfaulting?

[evilviper]

You keep harping on things like gcc 2.96...

I do? I mentioned it in two, short, sentences. One was in reference to the other, as well.

mentioning != harping

The thing was, everyone else proceded to have the exact same problems a few months later when gcc 3.0 was officially released. There WERE some compiler bugs in 7.0's gcc 2.96, but they were minor and fixed quickly. The REAL PROBLEM was that gcc 2.96 and thus gcc 3.0 enforced standards that gcc 2.x had always been lax about, and thus many programs needed small fixes in order to compile correctly.

No, on all 5 counts. See the standard form response: http://www.mplayerhq.hu/DOCS/HTML/en/gcc-296.html

So, if you're going to tell a user that their problems aren't problems, but rather stupid platform issues that the player can't possibly do anything but seg fault on,

That is generally the case. Media players, MPlayer in particular, are the first symptom of something being horribly wrong with your system, since they are so timing dependant, make extensive use of extended instructions (MMX, 3DNow, SSE, etc), lots of assember, etc. When system code is corrupt, or when your hardware is changing bits due to heat or other bugs, there's nothing programs like MPlayer can do about it.

you might want to talk about the current day and modern compiler releases,

Wait a minute. First of all, you JUST SAID that gcc 2.96 *is* current, or don't you remember?

"and 2.96 is STILL used in many production environments because of its massive improvements in the implementation of C++"

Besides that, I can tell you that I did see a strange bugreport on mplayer-users around a month ago, that was tracked-down to a gcc 2.96 bug. And I should mention that MPlayer works quite well on both 2.95.3 and 3.x, so you can't claim it's some strict rule somewhere, or C++ problem (MPlayer barely uses any C++).

And last but certainly not least, in the same breath that I mentioned gcc 2.96, I ALSO mentioned gcc 3.3, which most definately IS modern, and shipped with modern distros (Slackware 10 to name one). Of course, you selectively ignored that part, didn't you?

Re:When will it stop segfaulting?

[ajs]

You're getting way too upset about this. Please don't take this personally.

I simply said that mplayer (and gmplayer, as you correctly pointed out) crashes for me constantly, and I'm running a completely stock FC5+freshrpms system (and have had similar problems with every Fedora release I've used mplayer on).

Take that as an attack of some sort if you wish, but the fact of the matter is that the reason that I JUST NOW went to read Slashdot is that mplayer crashed at the end of a video file.

If distributions are breaking your software, you need to find out how and get them to fix it, as it is RUINING your reputation for me and anyone else seeing the same problems. If there's a bug... well, you can figure out where I'm going with that one.

I'll try to narrow it down with a small enough sample file that I can send in a bug report at some point, but hundreds of others MUST be seeing this, as I have nothing unusual in installation (fresh hardware and install circa 2-3 weeks ago).

Side note about gcc 2.96 (which I'm not using, I just get kind of touchy about the anti-2.96 comments because it was a vastly misunderstood release): You're bringing up some ancient history here, and yes, there are still buggy versions of 2.96 around (just as with any software), but they were fixed long, long ago. The only compiler bugs that I know of in CURRENT 2.96 versions are those that are endemic to the version (e.g. platform support issues which were addressed with major changes in 3.1+). If your bug reports are coming in from users who are using older revs, then there are workarounds that you could use to fix these issues, but you sound like someone who's not very interested in supporting 2.96 users, so I would suggest to them that they upgrade to the latest updates from their distribution vendor. The suggesting that there are problems with the latest version on that page you pointed to... well, perhaps there are (I'm sure there are in 3.4 or any random version... I assume about a bug per line of code in any software, and gcc has many lines of code), but unless you can narrow that hypothesis a bit more, no one is going to be able to write a fix.

The page that you linked to has some severe misconceptions about the history. I installed 7.0 the week it came out. I recall exactly what the issues were, and other than a few, very early problems that were mostly fixed by 7.1, and all fixed by 7.3, I've never seen a bug that was UNIQUE to 2.96 and did not show up in 3.0 a short while later. Of course, both 3.0 and 2.96 had problems, as they were major changes to gcc (hence the major revision). I would never suggest that someone use 2.96 if they are starting from scratch since it's so old, but if you're using it in a production environment, it's good enough at this point that updating isn't CRUCIAL.

Re:When will it stop segfaulting?

[ajs]

A side note. If you want anything in terms of debugging information, and you're in a position to actually move my bug report from Slashdot to something useful, I'd be happy to chat via email. I don't have a good sample video file as yet that isn't 300+MB, but drop me a line any time. I'm ajs at the like-named doamin in the dot-com namespace.

Re:When will it stop segfaulting?

[evilviper]

Well, the rule for MPlayer is that bugreports need to be against CVS, since it may have been fixed in the intervening year since 1.0pre7 was released. You didn't say which version you're using, but I assume it's 1.0pre7 (or earlier!). If you don't have the problems with the official RPMs or source, then the complaint should go to Fedora.

On the odd chance you can reproduce the problem with CVS, the bugreporting procedure is well documented: http://www.mplayerhq.hu/DOCS/HTML/en/bugreports.ht ml

If it's just another broken distro package... no, nobody wants to hear about it. That's the norm, not the exception.

If distributions are breaking your software, you need to find out how and get them to fix it, as it is RUINING your reputation for me and anyone else seeing the same problems.

The distros really don't give a damn. They completely ignore the packaging guidelines, make incredibly buggy MPlayer packages, and ignore all complaints. The nature of GPL'd software is that you can't force them to do anything, and they certainly aren't jumping at the chance to get their packages fixed.

What to do? Post a story on /. shaming them for their insanely broken packages?

I recall exactly what the issues were, and other than a few, very early problems that were mostly fixed by 7.1, and all fixed by 7.3,

Many people say similar things...

I've seen many people that, when told they have a hardware problem, respond, indignantly, that no other software has problems, only MPlayer. Then a few weeks later, you'll see a message from the same person, saying their CPU fan was going out, and appologizing...

MPlayer's aggressive code makes for the perfect test of any compilier... Every other application on the planet can compile perfectly, and yet you'll find bugs with MPlayer. -O3, -march, lots of ASM, 3dNow, SSE, MMX, etc.

Re:When will it stop segfaulting?

[ajs]

Thanks for the advice. FWIW, I'm running mplayer-1.0-0.26.20060314.fc5 which is built according to the followong spec file:

# cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/mplayer co -P
# cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/ffmpeg co -P
# cp -a mplayer MPlayer-%{date}
# cp -a ffmpeg/{libavcodec,libavformat,libavutil} MPlayer-%{date}/
# find MPlayer-%{date} -name CVS -o -name .cvsignore | xargs rm -rf
# tar cjvf MPlayer-%{date}.tar.bz2 MPlayer-%{date}/
Source0: http://www.mplayerhq.hu/MPlayer/cvs/MPlayer-%25{da te}.tar.bz2
%else
Source0: http://www.mplayerhq.hu/MPlayer/releases/MPlayer-% 25{version}%{?rcver}.tar.bz2
%endif
Source1: http://www.live555.com/liveMedia/public/live.2006. 03.03.tar.gz
Source2: http://www.mplayerhq.hu/MPlayer/Skin/Blue-1.5.tar. bz2
# Only for reference, required on YDL4 at least
Source10: uio.h-ppc.patch
Patch0: MPlayer-0.90pre9-runtimemsg.patch
Patch1: MPlayer-0.90-playlist.patch
Patch2: MPlayer-0.90pre10-redhat.patch
Patch10: MPlayer-1.0pre6a-fribidi.patch
Patch11: MPlayer-1.0pre8-udev.patch

Which you can see has 3 primary components, the 20060314 CVS source of mplayer and ffmpeg, liveMedia from 2006.03.03, and the "Blue" skin, as modified by 6 tiny patches which:

1. Fix 2 function prototypes for the platform
2. Change an error message so that it appears for 0 entries in a list as well as less than 0
3. patch configure to recognize "redhat"
4. change fribidi_flip_commas from 0 to 1 in subreader.c
5. and force udev checking in configure

So, as you can see, the Fedora install is pretty recent and fairly virgin in the sense that it has almost nothing unique about it. Now, I'm not clear on what liveMedia is, and perhaps that's considered ugly, who knows. But there you have the goods. If someone says "I'm running stock FC5+freshrpms, you now know what they're talking about (of course, the tricky part is the build environment which may or may not have been up-to-date with respect to updates when the package was compiled -- I recomend that you suggest to users that they re-build the SRPM in case of doubt, which is FAIRLY easy, at least compared to a CVS build, which most will botch or give up on).

"I've seen many people that, when told they have a hardware problem, respond, indignantly, that no other software has problems, only MPlayer. Then a few weeks later, you'll see a message from the same person, saying their CPU fan was going out, and appologizing..."

And I'm sure I've done something equally dense in the past... we all fall down sometimes. The thing is that I've been using Linux since pre-1.0 and Unix since the 80s, and I've contributed to open source projects many times... still, I find reporting bugs to mplayer to be daunting because of the time that the project requires that I spend in order to tell them about a bug. That means that, unlike say firefox, mplayer is disconnected from the woes of its userbase, and will mainly get bug reports that it is willing to cope with from developers and bleeding-edge users. This skews the feedback, and you develop a view of the user base which is not consistent with reality.

With fewer barriers to that process, you would get more representitive bug reports, and perhaps "I get seg faults all the time" would not come as such a shock.

"MPlayer's aggressive code makes for the perfect test of any compilier... Every other application on the planet can compile perfectly, and yet you'll find bugs with MPlayer. -O3, -march, lots of ASM, 3dNow, SSE, MMX, etc."

Surely. I would say that you're going to run into cache-related, bus-related, graphics-related and instruction-related issues that VERY few other programs will. That makes it all the more important that you understand the user base, work with the distributions and, where

Re:When will it stop segfaulting?

[evilviper]

So, as you can see, the Fedora install is pretty recent and fairly virgin in the sense that it has almost nothing unique about it.

Those 5 patches sound fairly scary, actually.

Now, I'm not clear on what liveMedia is,

That's the library for rtp/rtsp stream handling.

Re:When will it stop segfaulting?

[ajs]

"Those 5 patches sound fairly scary, actually."

You're joking, right? You honestly find those worrysome?

You have a one-character change to playtreeparser.c which, as far as I can tell is a bug fix to user-interface lossage, but worst case scenario displays an error when it should not.

The addition of the string "redhat" (one word change) in configure (sets system_name to Linux).

The removal of a startup status message regarding CPU detection.

Turning on a bi-directional text feature.

Forcing LIRC testing in configure (I assume this is because their build environment might have the LIRC headers and libraries, but no installed /dev/lirc, which is what configure tests for).

What about those is scary?

The only one that sounded sketchy at first was the parameter type change, but on reviewing that, I see that it's not the TYPE, but the parameter NAMES for readv and writev. My guess is that newer versions of gcc are enforcing matching names if names are used. This is probably something that was fixed in later CVS versions, since I assume the project would now have experience with more modern compiler versions.

All a guess, I admit, but it seems logical.

Still, I'm at a loss. Where's the scary?

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:DVD Menus & XMBC

[Chris Pimlott]

I found some technical information about XMBC's DVD player core. They do appear to be using libDVDnav, but there's no mention if they're using Ötvös Attila patch. They might have done it on their own; they were apparently were trying that approach previously in XMBP.

Regardless, I'm sure they've had to make some additional changes and modifications to fit XMBC's architecure and the Xbox's contraints. Hopefully they have pushed some of those back upstream when applicable.

GUI? Windows? Mplayer?

[caluml]

No!!! No GUI! Remember to stick to the path of Commandlinze, disciples!




GMPlayer doesn't count for this example. Don't ask me why.

Re:VLC or MPlayer

[Realistic_Dragon]

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.

And, importantly for some, provides plugin support for a whole crapload of stuff - especially on amd64 where realplayer seems not to want to go. With no mplayer I coudn't listen to BBC raido unless I wanted to muck around with the 32 bit bin version of firefox.

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

[shudde]

Maybe the attitude has changed by now, but MPlayer still got a black eye because manually trying to install it an exercise in frustration.

I remember trying to build MPlayer (and it's deps) from source a few years ago, it certainly wasn't an easy experience. That being said, in recent years I've been building it on LFS/BLFS systems following their instructions and found it works perfectly. I've also used those instructions (with some modifications) to build it on distros where I wasn't happy with the packaged MPlayer.

http://www.linuxfromscratch.org/blfs/view/svn/mult imedia/mplayer.html

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:I love MPlayer but...

[Anonymous Coward]

It is called the learning curve, and it wouldn't hurt you to remember that you had been there once. (not even necesarily computer related)

Re:I love MPlayer but...

[aug24]

Here's the GP's question in a google cache from 2004.

The answer, however, even two years ago read, "Add /usr/local/lib to /etc/ld.so.conf and run ldconfig."

Mind you, the whole post is a cut and paste troll taken from some old web pages, so really I'd just ignore the dickhead.

Justin.

Re:VLC or MPlayer

[dionoea]

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.

VLC also uses DeCSS. It is also able to use dmo windows codecs on unix (which makes WMV3 readable).

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:Xine can be used as a library

[evilviper]

Unfortunately, neither VLC nor MPlayer can be included as libraries in other multimedia applications.

You either don't know what you're talking about, or you're trolling.

No, mplayer can't be used as a library, but most of it's functionality comes directly from ffmpeg/libavcodec, which CAN be used as a library, and IS used by a HUGE number of projects.

Re:Xine can be used as a library

[rg3]

Being an MPlayer user, it's fair to say that xine-lib is the "good side" of Xine. I've only used it once in a program, and it made trivial for me to play a sound (and it accepted WAV, MP3...). ffmpeg is a much more low-level library. You can use it in your project, but it does not provide the same level of convenience or abstraction as xine-lib. That's why Amarok uses xine-lib, for example.

Re:Xine can be used as a library

[ookaze]

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

Of course, working with an embedded instance of MPlayer would be just stupid. What people do instead, is using the library associated with MPlayer : FFMpeg.
Now go look everywhere, you will see lots of projects using ffmpeg (like gstreamer).
So your argument about xine-lib just fell flat.

Re:Xine can be used as a library

[evilviper]

I've only used it once in a program, and it made trivial for me to play a sound (and it accepted WAV, MP3...). ffmpeg is a much more low-level library.

Xine-lib is right in the middle. At the low-end is libavcodec, then xine-lib, then at the ultra-easy end is MPlayer in slave-mode, which is also used extensively by many programs.

Re:VLC or MPlayer

[esocid]

MPlayer...the command line...in linux

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?

[grasshoppa]

dvd menus

Re:Is xine relevant?

[dabadab]

"[MPlayer is missing] dvd menus"

Oh, I thought that was a feature.

Re:Is xine relevant?

[dan the person]

Oh, I thought that was a feature.

It would be if it just went straight to the movie!

Half the time it just shows the copyright warning and exits.
Quarter of the time it shows the movie studio logo and exits
a tenth the time it shows some previews and exits.
the rest it actually plays the movie.

MOD PARENT UP

[molarmass192]

That's the cause in 99% of MPlayer segfaults. If all else fails, use i586 to build it or find an i586 binary. MPlayer gets very cranky when an i686 build is used on a non-pentiumpro CPU. However, MPlayer does very much rule, when DVD menus are added, it will be the best all around media solution for Linux. DVD playing on MPlayer right now is a bit tricky, you need to know the chapter you're looking for.

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

Re:Video on Linux

[dingen]

If your video doesn't play in VLC, Mplayer and Xine, it's probably not a video.

Re:Video on Linux

[jZnat]

This happened to me once. Turns out the video file was a garbage dud from when I copied it to a different hard drive earlier. I thought I deleted it, but a file filled with /dev/zero was in its place.

Re:Video on Linux

[gnud]

For the DVD, i'd also recommend trying out ogle, and spcifically the gui goggles.

Simpler?

[Derosian]

Am I the only one who would rather my media player have functionality but in the end be simpler. I use Media Player Classic. Nothing else needed, it plays videos...

Re:Simpler?

[PhakeDC]

I hear thou.. MPlayer Classic is decently simple and I recommend it to everyone I know (as part of the K-Lite Codec Pack). It even makes use of your 3D card if you want it to, so that $500+ card can actually be utilised outside the gaming environment.

Re:VLC or MPlayer

[pklinken]

I have a 400 mhz G4 Powerbook and MPlayer plays everything smoothly (usually even in reduced CPU mode).
However, if I have the Preview function in Finder turned on, and it tries to preview a 700 mb DivX, I end up killing Finder because it takes all CPU resources until it's done previewing (seemingly forever).

Re:VLC or MPlayer

[hunterkll]

70MB? You using quicktime? :D

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.

Re:MEncoder is fantastic

[evilviper]

I don't use MPlayer, largely because the built-in UI (or lack thereof) makes it a pain to deal with.

You've obviously never heard of gmplayer, which is the offical GUI, and comes included with MPlayer.

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.

No, you were probably derided because you were making mistakes very clearly covered in the appropriate section of the docs.

It's got a variet of filters, including I think 4 just for de-interlacing

Probably about a dozen deinterlacers, actually.

If you want to see some newbie bashing, the mencoder mailing list definitely a good place to hang out.

Since you make it sound like you were brutalized, I decided to go search the archives...

http://thread.gmane.org/gmane.comp.video.mencoder. user/973/focus=973
http://thread.gmane.org/gmane.comp.video.mencoder. user/1042/focus=1042
http://thread.gmane.org/gmane.comp.video.mencoder. user/1059/focus=1059

What I found were rather clueless questions, which could have been easily resolved by searching the mailing list for similar problems. And despite all that, you had perhaps a dozen different people posting multiple replies to your messages, giving very useful information without the slightly flaming.

I don't have any idea how you could consider that "newbie bashing".

Nice to see

[houghi]

that it is still alive and kicking. For you people that run SUSE 10.0 and want to have an easy way to install it:
1) Read this site
or 2) Open a terminal an type
wget http://houghi.org/script/MPinstaller && sh MPinstaller

Re:VLC or MPlayer

[evilviper]

I use VLC for my IPTV-provider, because RTSP sucks in mplayer (at least for me).

MPlayer uses the live555.com library for RTSP support, which is exactly the same thing VLC uses. Your problems are likely local issues (perhaps a binary package without live555 support?), and not actually problems with MPlayer.

MPlayer also gets its "hands dirty" with DeCSS and WMV "support" in *nix.

DeCSS was a Windows program. The Unix version was css-auth. Shortly after, libdvdcss was reverse-engineered to give legal DVD playback, and that is what has been used by every player (since about 2001, IIRC).

The ironic thing is, not only does VLC support libdvdcss, but libdvdcss was in fact written and maintained BY the VLC team, as you could tell from the fact that the official libdvdcss URL is on their server: http://developers.videolan.org/libdvdcss/

OH! OH OH! ME ME ME!

[PCM2]

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?

Number One!

No, wait ... Number Two!

Wait wait wait ... oh, damn, I was sure I had it right. Can't I have both?

I can? Oh, well that's fine then.

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.

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

[wodgy7]

If you go to the main MPlayer site, rather than the MPlayerOSX site, you'll see that they've released a much newer version only a few weeks ago (04/09/2006): http://www.mplayerhq.hu/design7/dload.html

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.

OK interview as far as it goes

[BluBall]

Would have been great if s/he asked about snow and nut. More importantly and relevant would have been to ask about mplayer g2. It's been moribund for awhile. I think this is why they were emphasizing the difference between developer and maintainer. Mplayer is just being maintained and new stuff is limited to tweaks it seems.

I say this as a long time and current user.

complete modularity of proprietary/patented bits

[richlv]

a lot of distributions do not include mplayer in their completely-free versions.
the reason ive heard of is containing of patented stuff if mplayer core that can not be easily modularised.

now, im not sure anybody qualified to give information will see this, but it would still be nice if some information could be given regarding this problem.
having mplayer included (probably as default media player) in more linux distribution could help it's usage enormously.

oh, another thing... last release has happened in quite some time. what happened to 'release early, release _often_' ?
no, cvs does not count. having more regular releases would help in getting the latest code to users both for creating positive impression and gaining wider testing audience.

yeah, in case it was not obvious - im using mplayer ;)
thanks for the great job.

Re:complete modularity of proprietary/patented bit

[evilviper]

the reason ive heard of is containing of patented stuff if mplayer core that can not be easily modularised.

Yes, pretty much ALL audio and video codecs you've ever heard of, or used are covered by numerous patents which require payment of royalties by the program maker. Companies like RedHat/Suse don't want to pay $10 in license fees for each user which downloads the distro.

It certainly can't be modularized, for performance reasons, nor would you want it to be, as MPlayer with 1 video codec is just as useless as not having MPlayer at all, and perhaps worse, because of people beliving that MPlayer sucks.

It's an idential situation as with Xine, VLC, etc.

oh, another thing... last release has happened in quite some time. what happened to 'release early, release _often_' ?

That's not MPlayer's credo. If you really care, the reason is because of a major hardware failure. The next release is probably only a few days away now, and you can grab latest CVS at any time.

Coloured subtitles

[fireman sam]

Maybe someone can answer this:

Everytime I rip a dvd with subtitles they appear white reguardless of the colour of the actual subtitles (in a standalone dvd player). This is because mplayer/mencoder changes only the luminance channel (so only brightness changes). However, the other day I ripped a dvd. The resulting avi had yellow subtitles. I have been unable to reproduce this, even with the same dvd.

Weird.

MPlayer in Windows

[javakah]

If you are ever stuck on a severely locked down Windows computer (that's has almost no codecs), use MPlayer! I tried a lot of programs in trying to be able to watch some of my videos (in several different formats). Unfortunately I was rather stuck because pretty much all other windows players depend on codecs being already installed on your computer (and try to install DLL's). Yeah, MPlayer has no real interface in Windows at the moment, but it rocks in that it doesn't need codecs and doesn't require admin priveleges to use.

Re:MPlayer in Windows

[Mitchell Mebane]

Or you could use VLC, which uses built-in FFMPEG and doesn't need admin privs, but has a pretty good UI.

mplayer as stream-analyzer

[losec]

I've played with "mplayer -v -vo null -ao null udp://224.1.2.3" as a frontend for analyzation of live streams. Pipe the stuff to a script. Put it in an loop so it restarts if mplayer dies. Its coarse, but it works.

Re:complete modularity of proprietary/patented bit

[Wesley Felter]

The solution is GStreamer; it's modular and Fluendo is working on legal proprietary plug-ins for it. Or you can download the underground plug-ins.

Re:complete modularity of proprietary/patented bit

[jZnat]

A quick question regarding your CVS repository: is head typically stable? Or do minor/major bugs slip in often enough to prevent one from wanting to stay up to date with head?

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:You are talking about two issues.

[toad3k]

Reencode clips to your format of choice. Supports every format out of the box. Is commandline, which gives you a ton of options on how to play files, giving you back some control. Can rebuild indexes on avis as you play. Does a lot better on damaged files (or files you are dling via bt). Oh yeah, not to mention you can dump streaming video/audio to your hd with no effort.

Granted I don't know that the windows version supports all this, but it will eventually. My only fear is that they will become dependent on windows.

Re:transcode

[evilviper]

i switched from mencoder after trying, and failing, to prevent it from dropping frames it decided were "similar" to previous frames.

No, mencoder only drops exactly identical frames.

If you were seeing a problem, it was a symptom of something else, and had nothing to do with the dropped frames.

Mencoder also has -noskip, -mc 0, -skiplimit 0, to prevent skiped frames (due to A/V sync issues), and to prevent "duplicate frames" from being dropped, you can use -vf harddup.

None of which will fix your problem though.

Yeah ...

[Ayanami Rei]

transcode (and then also mjpegtools) are kinda more of the attitude: do exactly this one thing and no more... for use in big conversion scripts and the like.

mencoder is more like: I just want you to convert this into this with this restriction and I don't care how you do it.

Of course, sometimes it guesses wrong about what you want it to do. Getting it do things a certain way can require black magic and animal sacrifice.

mmm :-/

[Ayanami Rei]

Rip your subtitles to a vobsubout .sub/.idx pair.
If you check the .idx file, you can see what colors it intends to use on playback in the header file. You can change them there (they're just like HTML colors, #RRGGBB).
Your .idx may be broken if you only get white text on playback. Check to make sure it's not trying to display a subtitle image at a weird time (often happens when ripping across cells when selecting chapter ranges)... that can confuse the playback software and cause it to miss settings or not display subtitles at the right times. I often have to hand edit the .idx files and tweak them myself.

Then again it could be an artifact of encoding the subtitles into the resulting avi. I don't use that method anymore, ever.

I encourage you to not encode the subtitles in the movie itself... but bundle it along (either as seperate files or as part of an OGM). It allows the end user to change color/transparency, move it, display it elsewhere (in the black bars going from widescreen->full, for example), and it improves encoding performance.

Re:complete modularity of proprietary/patented bit

[evilviper]

Yes, head is stable, for MPlayer at least.

It's usually okay if you want Mencoder, too, but occasionally a major mencoder bug will slip in and not get fixed for a few days.

Now that we're talking of MPlayer...

[WWWWolf]

...let's talk about mencoder.

Could someone please bring us some sanity to the command line, please???

The following might sound like a troll. It isn't. I love mencoder because it's just about the only video capture app that happens to even remotely work on my particular situation, and only modern video capture app I've seen, too - can do weird and obscure new things like V4L2 and ALSA, and its home page doesn't say "Updates coming next week! (last updated: Dec 2002)".

It's just it's command line syntax I have a slight problem with.

As a transcoding application, it's probably fine, but as a TV recording app, it just isn't that great because in order to do some even rudimentary capturing you need to specify a lot and a LOT of parameters. It would be nice to have a bunch of profile files, so that I could say "mencoder -conf big_mpeg4.conf -o randomgamecubing.avi" to capture full-screen MPEG4 and "mencoder -conf tiny_xvid.conf randomtvcrap.avi" to encode some 352x288 XviD?

The current solution is actually one of the most annoying solutions I've done so far - writing a shell script to handle that. Then, as in case of most shell scripts, it turned into a Ruby script. And then... ummmm... can anyone say if this piece of junk is, in any way, better than a configuration file? I don't think so myself.

Holy damn, if we don't get configuration files to mencoder, I may need to rewrite this thing in Common Lisp, and I assure that at that point, no one's going to have fun!

Re:Now that we're talking of MPlayer...

[azuretongue]

Type "man mplayer" and read the section about profiles.
Here is a teaser

EXAMPLE MENCODER PROFILE:

[mpeg4]
profile-desc="MPEG4 encoding"
ovc=lacv=yes
lavcopts=vcodec=mpeg4:vbitrate=1200

[mpeg4-hq]
profile-desc="HQ MPEG4 encoding"
profile=mpeg4
lavcopts=mbd=2:trell=yes:v4mv=yes

Re:Now that we're talking of MPlayer...

[WWWWolf]

::arms in the air and a desperate look at the heavens::

Well, you learn something new every day.

mplayer is a good effort

[sentientbrendan]

but VLC seems to work much better overall. At least the interface seems quite a bit better on the platforms I've tried it on. VLC does crash sometimes that mplayer doens't though, and mplayers performance is was quite a bit better than VLC for a while, so I guess its a toss up.

Also, last time I used mplayer, the required that you compile everything from source (no binaries available) for legal reasons. When I did this, by default a bunch of support for various codecs wasn't turned on by default. I remember complaining about that to someone who was extolling the virtues of mplayer, and they just told me to install it over portage. It wasn't particularly helpful, as I don't have portage *on my mac*.

Overall, VLC has impressed me as having vastly better usability and simplicity than any of the other video players (WMP, quicktime, mplayer, etc). Windows media player in particular, doesn't seem to understand that I just want it to dump the video to the screen, and not give me a bunch of bullshit playlists, and a menu bar that pops up whenever my mouse gets jostled during a movie... Really, all I need is an intuitive and non-distracting-by-popping-up-during-a-movie way to seek video and adjust volume, and yet many players insist on giving me soo much more than I need or want.

Really, how often do you make playlists of *videos*? That is a feature that needs to be off by default.

Re:mplayer is a good effort

[Chandon Seldon]

Different design goals for different audiences.

VLC is designed to work. All the time. When you download the binary.

MPlayer is designed to be fast. When you compile it with the correct options for your hardware. So you can get the best possible performance. Even if you're doing something silly like playing a high def XviD on a Pentium Pro that doesn't even have a GUI on it.

Version numbers

[achurch]

From the article:

Me: So when will 1.0 final come out (will it)?

Diego: To clarify this: our releases are not even beta, they are perfectly stable. But I suppose we will have to give in eventually and change the naming scheme to be more in line with people's expectations.
Alex: The problem is that a version of 1.0 can't be reached as new and new formats come every now and then. But the silly number still matters for users!

I can't tell whether the interviewees are simply trying to sound l33t or really don't comprehend the usefulness of (proper) version numbers to users, but either way I have to wonder: What is this resistance to the version number "1.0"? It's certainly not limited to MPlayer (I've been hacking transcode lately, and all the modules have version numbers of 0.something, or even 0.0.something), but everybody knows software changes--version 1.0 doesn't mean the end of the line; if anything, it gives users confidence that the program works.

Re:Version numbers

[waferhead]

Perhaps they ae just following Googles lead on making everything "Beta" forever? ;-)

mplayer rocks BTW, nothing else I've ever tried works as well, on everything that gets thrown at it.

(yes, possibly some work involved, but most likely it WILL work when nothing else available will)

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.

MPlayer - let's not forget A'rpi!

[DrunkenPenguin]

It is nice to notice that there are some people who keep on developing MPlayer, but let's not forget A'rpi! A'rpi is the man who has saved our days so many times in the past! I remember those days in 2000 / 2001 when there was not a single decent video player (yeah, I tried them all) for Linux and then I discovered MPlayer. Microsoft's .asf was hot format back then and soon you could watch .asf videos with MPlayer on Linux. I remember the feeling I had when that was possible. It was like "Fxxk you Microsoft, you can keep your codecs secret, but A'rpi can crack 'em anyway".

So, Thank You A'rpi! For all your efforts! What you have created is the best mediaplayer on this planet. Period.

Maybe...

[crispy_one]

There will be a new version the next time a PC game is ported over to OS X...

M4V Support?

[TheoMurpse]

Is there any hope that support for iTunes videos will be coming? I subscribe to a free video podcast through iTunes called Happy Tree Friends. I wish I could watch these podcasts on my hacked XBox (XBox Media Center is based off of MPlayer), but this codec is not supported. iTunes does not play video on my computer (my laptop isn't powerful enough), so I'm left without a way to watch these podcasts. As I don't think free podcasts are encrypted with a FairPlay-type system, I don't think there would be a legal issue here.

Re:complete modularity of proprietary/patented bit

[LackThereof]

From TFA:

"We only support self-compiled releases from latest CVS."
"It's not alpha, what we put out are releases. And CVS is stable as well."