Slashdot Mirror


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

17 of 334 comments (clear)

  1. Congrats to the MPlayer team! by Longinus · · Score: 5, Interesting

    .90 has been a long time in coming, but the wait was well worth it. I continue to be astounded by what mplayer and mencoder are capable of, and I shudder to think of what my Linux movie watching experience would be like without them. I hate to sound like a cheer leader, but I just don't think enough can be said about the fine work that A'rpi and Co. have produced over the years. In addition to our beloved kernel, it's always nice to have examples of open source software that so readily stomps into irrelevance its closed source competition. Good luck to A'rpi in whatever the future holds, and a thousand thanks for your contributions to the community.

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

    2. Re:Congrats to the MPlayer team! by vandan · · Score: 4, Insightful
      By using closed source binary codecs stolen from proprietary closed source programs?

      It depends on what you're trying to achieve. If your first priority is to make a movie player / encoder package for Linux that rocks, then you may have to make compromises with your purest vision of open source technology, at least for a period.

      Of course each person has the option of not downloading and using the windows binaries, but I will guarantee that for those who use mplayer as their main video player, when they have the choice of using mplayer's .dll loading capabilities or switching to another video player that has a native linux decoder, they will stick with mplayer. It's nice to have ideals, but when you're watching a movie, you care more about how the movie looks / sounds than whether you have win32 dll loaded.
  2. THANKS ARPI! by Anonymous Coward · · Score: 4, Insightful

    A GREAT BIG THANK YOU TO YOU AND THE REST OF THE MPLAYER TEAM!!!

    You saved our day when there was no decent video player for Linux some two years ago. You brought us the Microsoft ASF fileformat support and Sorenson Quicktime.

    I will never forget.. MPlayer played a vital role in Linux's success. The best videoplayer on this planet! So fast it's hard to believe!

    1. 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. well by daserver · · Score: 4, Informative

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

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

  6. Re:yes, exactly because of that by October_30th · · Score: 4, Insightful
    I don't give a shit. I rather like Linus' using-the-right-tool-for-the-job attitude. If there is an open source alternative to closed software, that's fine and dandy. If there is no feasible open source alternative, using proprietary software is just fine.

    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?

    --
    The owls are not what they seem
  7. 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!

  8. Maybe we'll finally get some threading by sanemind · · Score: 5, Interesting

    Of course, I don't mean to complain, for goodness sakes. A'rpi has done an amazing job. I recently introduced a friend of mine to linux, and he was awe-struck by the huge functionality and flexibility of mplayer. I will always be greatfull for the development that has gone into this wonderful program that I use every day.

    Mplayer only just recently got inverse-telecine, which is a Good Thing for those of us who like to archive a lot of shows.... I used to have to use virtaldub under wine if I wanted to get IT done right [for truly treasured movies... the rest I just deinterlaced and accepted the quality loss].

    The only remaining quibble I have with mplayer, actually most specifically with mencoder, is the lack of any threaded/forked/etc rendering pipeline. I am somewhat in the minority in having a SMP system, but there are a good deal of us out there. It causes me such pain to not have quite enough cpu to do certain realtime effects while encoding, to fall behind, while I see CPU0 pegged to 100%, and CPU1 just sitting there idle.

    There was a big occasion for disagreement a while back, when someone tried to get some threading into mplayer, even had working patches. A'rpi refused. He had somewhat of a point; the context switching overhead actually wastes cycles on a single processor. [As well as flushing the cache at inoportune times]. Threading on a uniprocessor system would only really help with I/O latencies, but mplayer has great cacheing, and manages well, even with just a single context.

    I'm torn between being hopefull that maybe there will be more openess to future improvements such as SMP support, but I'm also sad to see such a wonderfull developer throw in the towel. MPlayer probably wouldn't have happened without him.

    --

    ---
    the pen is mightier then the sword. the sword is mightier then the court. the court is mightier then the pen.
  9. Re:Attitude by SilverSun · · Score: 5, Interesting

    And I really hope they loose theit fear of Version number 1.0. I am pretty amnazed that Arpi leaves without having a half decent 1.0 out. gui is still disabled by default. Why? Largefiles: disabled. Why? The output mplayer sends to stdout is still a incredible mess. I wonder why he leaves the project without cleaning up these few last bits. In principle MPlayer is the most usable, stable, and featurefull media player for linux. Only thing is, it's a mess.

    I hope the first thing they do is clean up the code. MPlayer lost _many_ developers to xine lately. xine has not caught up to MPlayer in speed and number of supported formats. Also it seems to be still less stable and more vulnerable to broken video files, but the code base is MUCH more clean (xine sources can actually be called beautifull) Maybe this disruption of MPlayer development can also be seen as a chance for a more unified default mediaplayer for linux, i.e. xine.

    The one thin xine is lacking is an encoder a la mencoder. But there is some development with enix. The design looks as clean and easy as xine and I am pretty confident that enix can catch up to mencoder in a short time provided that some more developers are interested.

    Cheers

    --

    KdenLive/PIAVE - non-linear video editing

  10. Re:Gstreamer (and xine?) by groomed · · Score: 5, Insightful

    I think the last thing the world needs is another media framework. Not that it's a bad idea per se, or that gstreamer is bad. But there are too many perfectly good frameworks already. And they all have one thing in common: while they promise ultimate flexibility and all kinds of ubercool features, in practice, only a few combinations of plugins work really well. And even those would have worked better if they had simply been integrated into a single app.

    What we need is code that does heavy lifting. Code that can read and write all sorts of file formats and that can do so at blistering speeds. But that requires mindnumbing attention to detail and painstaking testing on a wide range of different files and machines. So that most people prefer to indulge in the fantasy that all of this difficult work will just somehow evaporate, just as long as there is a good framework: "it's the bureaucracy, stupid". Of course, that rarely, if ever, pans out. At best, the grandiose Framework is reduced an API for manipulating media clips (QuickTime). At worst, it forever remains a flaky research project to satisfy the will-to-power of a few geeks and true believers (http://www.sourceforge.net).

    Now that last part was a bit flamebaity. But what I'm trying to say is that instead of spending time on developing a "media framework" that can do "every conceivable thing", is almost always better to spend your time considering which of those "conceivable things" actually makes sense: and implementing that.

  11. Re:A'rpi ? by Anonymous Coward · · Score: 5, Insightful

    "How do I..." "RTFM IDIOT!!!11"

    You mean THAT A'rpi ?


    I think that attitude is something that easily happens if you invest too much time and devotion into a project, especially if that project is really rather complex and draws the attention of a lot of newbies to Linux who want to watch vidz. If you're trying to focus on the development with hundreds of dependencies to keep in mind and every day you get the same "How do I.." FAQs on the mailing list, I guess you tend to go down the "It's in the docs, check the README file", "Please read the docs, it's all in there", "PLEASE read the docs, we didn't write them for fun" "READ THE GODDAM FUCKING DOCS!!" route rather quickly.

    Maybe projects like this should have separate PR people who are not as directly involved with development but know enough about the project to hand out clues to newbies, keeping the coders free to focus on deeper things.

  12. So much hostility... by entrigant · · Score: 4, Insightful

    Most everyone here should know that a free project with no incoming profit stream usually comes with that big "no warranty expressed or implied" disclaimer, and no technical support. This, however, is only a disclaimer, and a lot of project development teams are very helpful and responsive to users questions. This is a good thing that is happens so much, but as usual there is a dark side. Users become 4 year old spoiled brats.

    I've had no personal experience with this guy before, as I haven't run into a problem in mplayer I couldn't fix myself from RTFM/S (Reading the ... Manual/Source), but from what I hear he has no desire to play tech support guy for the hundreds of users of mplayer. What should we think of this? I think that I don't blame him, I'd be telling people to F Off too, I don't have time for that shit. Is free not enough for you people here? I'm sick of seeing crap like "I would use MPlayer, but the author told me to RTFM!"

    Boo Fucking Hoo

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