Slashdot Mirror

← Back to Stories (view on slashdot.org)

MPlayer 0.90 released; MPlayer Maintainer Leaves

Posted by timothy on from the plays-what-you-throw-at-it dept.

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

25 of 334 comments (clear)

  1. well by daserver · · Score: 4, Informative

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

  2. Re:THANKS ARPI! by den_erpel · · Score: 4, Informative

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

    --
    Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."
  3. Embedded Mplayer by mrsev · · Score: 5, Informative

    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.

    1. Re:Embedded Mplayer by The+J+Kid · · Score: 3, Informative

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

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

      --
      Moderation: +4. Modded 70% Funny and 30% Overrated. 100% Saturated.
    2. Re:Embedded Mplayer by the_real_tigga · · Score: 4, Informative

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

      --
      my .sig is better than yours.
  4. Re:Congrats to the MPlayer team! by Longinus · · Score: 4, Informative

    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.

  5. will it lose the race against xine? by Pivot · · Score: 5, Informative
    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...

    1. Re:will it lose the race against xine? by rjw57 · · Score: 3, Informative

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

      --
      Rich
    2. Re:will it lose the race against xine? by SuperBanana · · Score: 2, Informative
      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-.

      --
      Please help metamoderate.
  6. I just completed downloading it! by Xpilot · · Score: 1, Informative

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

    --
    "Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
    1. Re:I just completed downloading it! by 13Echo · · Score: 2, Informative

      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.

  7. sync issues by Anonymous Coward · · Score: 2, Informative

    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.

  8. Re:Windows port? by Xugumad · · Score: 3, Informative

    According to the FAQ you can compile it on Windows using Cygwin. On the subject of ports, Mac OS X users may be interested in MPlayer OS X.

  9. Re:yes, exactly because of that by Longinus · · Score: 3, Informative

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

  10. MPlayer rocks! by cdemon6 · · Score: 2, Informative

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

  11. Re:Windows port? by bodin · · Score: 4, Informative

    If you need a really good mediaplayer on windows, mac or other platforms, please check out VLC http://www.videolan.org/vlc/ 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!

  12. Awesome by ThundaGaiden · · Score: 1, Informative

    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

  13. Re:Windows port? by KAMiKAZOW · · Score: 2, Informative

    Check out Media Player Classic or jetAudio.
    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).

  14. Re:Idea for a new media player by rjw57 · · Score: 3, Informative

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

    --
    Rich
  15. Re:Idea for a new media player by MrMickS · · Score: 2, Informative
    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.

    --
    You may think me a tired, old, cynic. I'd have to disagree about the tired bit.
  16. Re:Maybe we'll finally get some threading by Caligari · · Score: 2, Informative

    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!

    --
    The moving cursor writes, and having written, blinks on.
  17. Re:Congrats to the MPlayer team! by Anonymous Coward · · Score: 0, Informative

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

  18. Oh come on... by Replicant7 · · Score: 4, Informative

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

  19. Re:non-DVD subtitles? by soccerisgod · · Score: 2, Informative

    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

    --
    If a train station is a place where a train stops, what's a workstation?
  20. Re:mencoder directly to VCD/MPEG1 or SVCD/MPEG2? by Abcd1234 · · Score: 2, Informative

    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, encode the video from the yuv4mpeg stream, and use toolame 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...