MPlayer 0.90 released; MPlayer Maintainer Leaves

Viqsi writes "459 days after the previous stable release, the MPlayer folks have finally released stable version 0.90. With this done, A'rpi (th head maintainer) is leaving the project, citing too-much-free-time-forever-lost issues, and the team is looking closely at revising the way the project is managed as a result. Here's hoping some improvements come out of this."

well

[daserver]

Well Arpi is still there on the mailinglist doing stuff, he's just not the maintainer any longer.

Re:THANKS ARPI!

[den_erpel]

Next to this obvious cheering, it is a fact that mplayer is the most versatile player around that I can think of. I've seen lots of cases that mplayer is capable of player files with odd framerates (audio and video, mainly produced by a bad configured digital camera) while other (includeing M$ mplayer) players choked on it.

Since the license change, I've seen that (that allowed binary packaging) it is gradualy pushing other players to the background, exaclty due to it's versatility (aviplayer, xine, vlc, ...)

The documentation seems to be somewhat lacking and for some things I (still) use IMHO better tools:

video recording: nvrec, AFAIK mplayer does not support V4L2
encoding: transcode, mainly because transcode seems to have a much better doc and logical buildup of the options to transcode and large modularity (for filters). I use mencoder sometimes when transcode has problems with particular file (or used to)

One thing which no player seems to pull of correctly, is to play files with awfully synced audio, video...

Embedded Mplayer

[mrsev]

Not many know this but texstar has a awesome package for embedding Mplayer into Konqueror. This is just awesome.

Big thanks to the developers., for this one.

Re:Congrats to the MPlayer team!

[Longinus]

MPlayer ability to play hacked codecs is indeed a nice feature, but there's so much more the love about it, especially in the realms of performance (extremely low CPU usage), interface (sweet, sweet, command line, anti-aliased subs and osd), and flexablity (lots of other programs use mplayer, like MythTV and the mozilla-mplayer plugin that allows Linux users to watch movies in their browser). MPlayer manages to do a crap load of things without being bloated or slow.

will it lose the race against xine?

[Pivot]

From his second posting;

> IMHO mplayer is good enough now that it won't lost in /dev/null if i leave.

> > Probably not, but will it lose the race against xine?

imho we lose it already. see xine, its popularity started to grow since a month and keeps growing. while we spend our expensive time by rev. engineering codecs, optimizing code, writing demuxers, they improve the gui. then they 'steal' the others and win. we have no chance against xine... Ah, stability. Yes, in old days mplayer was rock solid while xine crashed at every second click. It has been changed: mplayer is now everything but stable (thanks to that many hacks and 10l bugs), while xine improved stability a lot...

I just completed downloading it!

[Xpilot]

Ha! Take that Slashdot!

I'm currently making some Slackware 9 packages for it. I'm trying to get it to compile with the Quicktime codecs, but it seems kinda broken (I probably screwed up somewhere)

The new default skin is really cool looking...

Re:Embedded Mplayer

[The J Kid]

There is also an embedded Gnome 2 Mplayer called: Lumiere.

It's just started, but already usable and quite nice. Very promissing.

sync issues

[Anonymous Coward]

to fix sync issues, use... get this.... mencoder. I shit you not, this does the trick. I've often been bothered by bad sync from files I find, even on a good system (1.8Ghz...), but if i use mencoder to remultiplex the file the vast majority of the time the result is a perfectly playing file.

mencoder -o output.avi -oac copy -ovc copy filethatsyncsbad.ext

It even makes files that play correctly play more smoothly.

Re:Windows port?

[Xugumad]

According to the FAQ [mplayerhq.hu] you can compile it on Windows using Cygwin [cygwin.com]. On the subject of ports, Mac OS X users may be interested in MPlayer OS X [sourceforge.net].

Re:yes, exactly because of that

[Longinus]

"I merely pointed out the hypocricy of calling MPlayer an open source revolution that stomps closed source into oblivion when its core performance is enabled by closed source (unlicensed) binaries?" What bullshit. MPlayer's "core performance" remains the same whether or not it was compiled with support for Win32 codecs. I do use the right tool for the right job, and that tool is MPlayer. The ability to play Win32 codecs is merely a bonus to me, and help in a pinch whenever I have the misfortune of needing to watch a Real video clip. 99% of my videos are encoded in open codecs like XviD anyway. The point is that MPlayer rocks regardless of what codec its playing, and to say that its only value is the ability to play win32 codecs is to be completely ignorant to what an amazing piece of technology it is in it's own right.

MPlayer rocks!

[cdemon6]

MPlayer in combination with some scripts can do incredible things - for example watching dvds/svcds/files via tv out is done via a small script my system and every time i am running windows i reboot to view movies, and it takes far less time than using tvool cracked version xxx1024-whatever and trying media player, powerdvd, divxplayer etc. to play some region-encoded dvd, some file which codes is rather new and not found or something...

Re:Windows port?

[bodin]

If you need a really good mediaplayer on windows, mac or other platforms, please check out VLC http://www.videolan.org/vlc/ [videolan.org] which is a VERY good alternative to both XINE and MPlayer. It plays video directly out of bin/cue-files and does all sorts of good stuff.

Free of course. Sister project is free videostreaming!

Re:Embedded Mplayer

[the_real_tigga]

there is a package called mplayerplug-in [sourceforge.net] which provides a plugin for all netscape-compatible browsers (including opera).

Awesome

[ThundaGaiden]

I've been using this player religously ever since
I moved to linux , and now that they've chosen
a default skin , I hope they incorporate it into
the project properly (ie default download ,
compile includes it)

I love showing my 'doze friends look I'm playing
an avi , followed by a dvd , vcd , mov , rm ,
etc... all from the same program !!! They just
look flabbergasted and upset.

Then I go look I'm re-encoding using the same
program (well source base at least) and once
again they're flabbergasted , and wow hey no voice
sync problems either :D

This is definatly one of the programs that makes
my life a lot easier using linux

Re:Windows port?

[KAMiKAZOW]

Check out Media Player Classic [edensrising.com] or jetAudio [jetaudio.com].
Both player are able to handle all DirectShow codecs (incl DivX) as well as RealMedia, QuickTime, and also DVDs.
jetAudio installs the RealMedia codecs, but no QuickTime codecs. Media Player Classic installs no codecs at all (that's why it's so small).

Re:will it lose the race against xine?

[rjw57]

And it was the xine guys (erm... OK hands up, me) who first separated the DVD nav stuff from Ogle sufficiently to be used in other projects (including, now, mplayer).

Re:Idea for a new media player

[rjw57]

The GStreamer [gstreamer.net] project aimed to do this and xine already has support for demuxer, codec, output, etc plugins (indeed all the DVD features used by xine used to exist as a totally separate project at dvd.sf.net).

Re:Idea for a new media player

[MrMickS]

Basically, perhaps the best idea for a media player, is to work-out a robust, system-independant, plugin mechanism. That way, everything else (audio/video output, interface, etc) can be done seperately from the decoding/encoding. A media player is much more useful if you don't have to recompile it to add support for one more format. Windows Media Player, Real Player, and Quicktime all have the ability to download plugins, the only problem is that they are very-much system specific. If there was a system-independent plugin mechanism, there wouldn't be so much redundant work, with everyone doing the same things from scratch, for each player, and on each platform.

Then we would be pretty much dependent on the speed of the CPU rather than any nice tricks that the different systems are capable of. Examples:

Apple makes uses of Altivec instructions in the G4 to get improved performance on the sort of ops that these plugins do.

SGI IRIX based systems make heavy use of the graphics subsystem (which is why they still command big bucks) for this sort of operation.

What you suggest wouldn't gain much approval from users as it wouldn't allow them to use the full power of the machines. Imagine having a system with a new graphics card and getting poor frame rates because the plugin didn't take advantage of the features of the card.

Re:Maybe we'll finally get some threading

[Caligari]

For your information, there is actually a fork of the main MPlayer which implements multithreading.

Not sure how good it is since I don't have an SMP system, but it does exist.

http://mplayerxp.sourceforge.net/

Ah, the boon that is Free Software. Have a problem with something? You can modify the source and fix it yourself!

Re:I just completed downloading it!

[13Echo]

You don't need to add any special compile-time flags for Quicktime anymore. That changed about 3 or 4 releases ago. ./configure --enable-gui --prefix=/*temp dir*/usr/

should suffice for a Slackware 9 system (It's what I use). Be sure to put your codecs in /usr/lib/win32 before compiling, and then copy them to your tarball directory before running "makepkg". Be sure to keep the same directory structure. Run "makepkg" in that temp directory.

Re:Congrats to the MPlayer team!

[Anonymous Coward]

mplayer? Plays everything? You obviously don't use powerpc-*-linux or alpha-*-linux :3

Yes, obviously. Duh. What, you think running Windows on powerpc or alpha is going to solve anything? And yes, I'm quite aware that there is no Windows for powerpc...

Oh come on...

[Replicant7]

This has changed dramatically. No, seriously you are talking about the past. Which parts of the documentation do you find lacking? I'm the documentation maintainer and I will try to address the points you may make...

Re:non-DVD subtitles?

[soccerisgod]

If this is any help to u, mplayer tries to open files with the same name as the movie file minus extension plus one of these extensions:

utf, UTF, sub, SUB, srt, SRT, smi, SMI, rt, RT, txt, TXT, ssa, SSA, aqt, AQT

Re:will it lose the race against xine?

[SuperBanana]

while we spend our expensive time by rev. engineering codecs, optimizing code, writing demuxers, they improve the gui. then they 'steal' the others and win. we have no chance against xine

As usual, he's got a major chip on his shoulder. It was always one thing or another:

-compilers that caused the program to crash or do odd things(mplayer's configure script would refuse to run unless you had certain versions of GCC, and no- it wasn't 'the broken one that shipped with redhat' that it would object to). Funny, but nobody else had such unusual compiler requirements.

-licensing problems(some of the rants are truly spectacular.) At one point he went and dug up other projects that he felt were worse violators, as if to try and shift people's attention/justify his own problem. It was pathetic.

-Distros "incorrectly building" the player(I think it was how they were linking to libraries), which would then send floods of users to them(and, of course, they think all their users are idiots). Mplayer is by far the most anal-retentive about distribution of binaries, and as a result, the distros have told them to kiss off distro-style(ie, mplayer's been dropped from the major distros)

Mplayer got a bad review for (surprise!) having "developers [who] were unfriendly and ... documentation incomplete and insulting." His response? He attacks the author of the review with several bullet-points in the DOCS TO MPLAYER ITSELF! As someone once told me, "it's better to keep your mouth shut and let people wonder if you're an a jerk, than to open it and remove all doubt."

In each case, it was "mplayer versus the world", and in his opinion, the world could go screw itself. The docs, the website, even the messages in the configure script and the program itself- were all confrontational, and/or insulting; sorry, I don't like software that cops an attitude. This guy, if not the entire team, had serious problems with keeping their mouths in check. So, when I hear he's leaving, I can only say GOOD.

As I download this latest release, I can't help but remember how nothing changed with each release candidate up to this; the volume control doesn't work, the OSD is broken, some files give it complete conniptions but play fine in Xine, and it takes an enormous amount of CPU power now. Used to take about 2-5% of my CPU, now it takes 50%. Playback is jerky, too. Xine? None of these problems(sync is often better, playback is smooth, CPU usage is minimal/non-existent.)

Maybe the reason he's pissed off is because Xine is using his code(as they can- if you didn't like the concept of others using your code, you shouldn't have made the project open-source), but using it -BETTER-.

Re:mencoder directly to VCD/MPEG1 or SVCD/MPEG2?

[Abcd1234]

I would just use mplayer with the yuv4mpeg video output driver, and the PCM audio output driver. Create two fifos, one for the video called stream.yuv and one for the audio, say audio.wav, and tell mplayer to write the video and audio to the fifos. Then, using mjpegtools [slashdot.org], encode the video from the yuv4mpeg stream, and use toolame [slashdot.org] for the audio. Then, mplex the resulting streams together, and voila, you have a VCD or SVCD.

Something like this should work (for VCD):

mkfifo stream.yuv
mkfifo audio.wav

mplayer <tv options here> -vo yuv4mpeg -ao pcm -aofile audio.wav < /dev/null &
cat stream.yuv | yuvdenoise | mpeg2enc -F 4 -f 1 -n n -a 2 -o video.m1v &
toolame -b 224 -m s audio.wav video.mp2
mplex -o video.mpg video.m1v video.mp2

'course, this is all assuming your box can handle decoding the TV stream and encoding the video and audio simultaneously. :) OTOH, if you're running an SMP box, this technique is probably more efficient...