Slashdot Mirror


Mplayer Revisited

Joe Barr writes "It's been two years since I first wrote about Mplayer. Maybe the fury of the developers/community reaction to the fact that I dared to criticize them for their treatment of users kept me away. Whatever. Now Mplayer has a pre1 version of release 1.0 out there and it's time for another look." Newsforge and Slashdot are both part of OSDN.

27 of 353 comments (clear)

  1. Great for OSX by truffle · · Score: 4, Informative

    The OSX build of MPlayer is very useful, it's the best DivX player for OSX! Of course it plays other formats as well. Thanks MPlayer team!

    --

    ---
    I support spreading santorum
    1. Re:Great for OSX by Fred+IV · · Score: 5, Informative

      VLC is pretty good too, better for me because my mac is an older machine and the OS X version of mplayer doesn't always work well with my hardware (iBook 500).

  2. What about other software? by Kandel · · Score: 3, Flamebait

    Sure, it's great to have a v1.0 release of MPlayer, but on the other end of the stick, Xine is not far off from hitting the 1.0 status as well. Won't this seem daunting to the end user (labelled automatically as stupid), having two different applications, with individual libraries, for doing the exact same thing.
    Perhaps some collaboration between MPlayer and Xine should occur.
    However, the fact I find most surprising, is that Microsoft hasn't stepped in argueing that the software cannot be called, "MPlayer". Perhaps it's 1.0 status may spur things on...
    Let's hope the MPlayer guys don't ship their next release as version 9.0 :P

    1. Re:What about other software? by sewagemaster · · Score: 4, Funny

      Let's hope the MPlayer guys don't ship their next release as version 9.0 :P

      actually, it wont. thanks for the clue michael has told us. this version v1.0 is named mplayer revisited. when the next verion comes out v2.0, it'll be called mplayer reloaded. within the same year, v3.0 will be out and named mplayer revolutions. in between each released version, we have v2.5 mplayer reloaded extended DVD edition, and v3.5 being reloaded extended DVD edition.

      Dont forget animplayer, the game enter mplayer, the comic book to be released, and the new roleplayer game to be released!

    2. Re:What about other software? by Qzukk · · Score: 4, Insightful

      Won't this seem daunting to the end user ... having two different applications, with individual libraries, for doing the exact same thing.

      So, you think we should all just go with one software project and kill the other? Which should we kill? Did you know that Xine did the GUI thing first? Mplayer has been the leader in figuring out how to play new formats (especially Quicktime codecs)

      So if we had killed xine, would mplayer have developed a gui without competition? If we had killed mplayer, would we still be griping about not being able to watch Sorenson encoded movie trailers?

      What future benefits will this competition bring?

      To the users, I say: Try them both and stick to the one you like. This doesn't require genius or even much intelligence. If you can't get mplayer working, then xine. If you'd rather not deal with a GUI, then mplayer. (personally, I hate hunting through a list of files for the video I want, when I could just run mplayer -fs filename.avi and get full screen goodness straight from the start without having to move widgets out of the way or get them behind the video window.)

      --
      If I have been able to see further than others, it is because I bought a pair of binoculars.
    3. Re:What about other software? by Dave_bsr · · Score: 3, Insightful

      Hey, it's the overly critical guy again. I really think you might just be a great, great troll. Either that or just really frustrating. Anyways...response:

      For one, groups don't always just get along...I really don't think the xine guys and the mplayer guys would like to just drop everything and work together - both sides have thrown a couple of potshots too many - they don't like each other.

      Secondly - competition increases output. It's one of those crazy things about life that two competing groups seem to get farther than only one alone.

      Third - more people on a project does not (neccesarily) more code make - adding more developers means you have to merge maintainers, and "people in charge" - etc - it has to be very well organized to get O(n) increase in production... You can't just throw people from well-defined, properly working groups together...it doesn't work! Good people can be left out (and unused)...

      Fifth - mplayer and xine do share some libs. I'm almost positive that xine is using some of mplayer's win32 code, but i'm not sure - but the logical thing is that they are both open, and why wouldn't one project "borrow" code from another, if it was great. Emulation is the sincerest form of praise - I think that's how that goes.

      Mplayer is a great project, xine - last I checked - was...decent. I think seperately you get _more_ output - and thus having two seperate groups is better for you. *shrug*.

      --


      Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
  3. Of course you were criticised! by 91degrees · · Score: 4, Funny

    I mean, imagine suggesting that a Linux user might not have a full and completye knowledge of the system, or that anyone should install Linux without first knowing absolutely everything about it.

    Are you an idiot? The MPlayer programmers were born with this information (which does probably make them about 12, which kinda figures).

    Rather than complaining you should be grateful and worshipful that they deigned to come down to this level, and allow us mere mortals access to their holy media player.

    1. Re:Of course you were criticised! by Anonymous Coward · · Score: 3, Insightful

      "I know it's illegal, but could you add DVD Support?"
      "Why won't it Play DVD's?"
      "I can't watch my DVD"

      That's enough to make me cynical.

    2. Re:Of course you were criticised! by curne · · Score: 5, Insightful

      Much amused.

      But I cannot say I agree. I find it refreshing that a development team develops a high end program that requires some seriousness of people to use. It is becoming a widespread myth that free software developers are little Tele-tubbie-happy people just sitting on their asses coding for hundreds of idiots that luckilly flock to their mailing lists.

      MPlayer is a fantastic program (along with other fantastic media programs running on Linux & Co) so many users want it to work for them. And I think that the MPlayer core team acknowledge that but when you for time number 796 get an email reading 'I problem compiling, Please help!!! Is it bug?' with no log or dump... well the coding gets sour. So I can understand that criticism is difficult to take. Especially when it seems as unfounded as the first review.

      --
      All interpreted languages are abstractions over Lisp
    3. Re:Of course you were criticised! by squiggleslash · · Score: 5, Interesting
      Barr was criticised for quoting the FAQ out of context (an obviously tongue-in-cheek comment was quoted as some sort of flame of end-users) and criticising a pre-release program for faults also present, at the time, in Xine which he subsequently gave a rave review (the faults in this case concerned dependencies - Xine and MPlayer had more or less the same dependencies, but he ignored them in Xine's case and made a big deal of having to find them in MPlayer's case.)

      I fully understood the frustration the MPlayer community, which in my experience has always been very helpful and very proactive trying to create something that'll be ideal at the end of it (they may be wrong in some of the directions they've taken, but I don't doubt their motives), and really found the Barr article and his apologists somewhat disappointing. Barr really seemed to write the article in order to fire up a storm, certainly the quote out of context, an aggressive maneuver which it's hard to believe wasn't deliberate, backs this up.

      --
      You are not alone. This is not normal. None of this is normal.
  4. Why review only the beta version? by TheOrquithVagrant · · Score: 5, Informative

    MPlayer 0.92 is the current stable release where everything works as expected.

    MPlayer 1.0-pre1 has some nice new stuff, but even though it has one thing (support for input from v4l devices with hardware MJPEG support) which I've wanted ofr a long time, the current pre-release is much too flakey for me to use, and I've gone back to 0.92.

    MPlayer 1.0-pre1 is for writing bug-reports, not reviews.

    Unless Mr. Barr had a conscious or subconscious WISH to find things that didn't work right, i don't see why he wrote his review for the pre1 version.

  5. MPlayer has matured... by Valar · · Score: 5, Interesting

    MPlayer has matured, both in code and attitude over the last year or so, or at least I've found it to be true. I never really had trouble installing it in the first place (all you had to do was *gasp* read the directions and follow them), but the install has gotten easier. I find that it also works better on my PC now. Additionally, their teams seems to had lost a bit of the attitude-- a quick glance over the docs doesn't reveal any references to how stupid the average mplayer user is :). Maybe they finally realized that attitude was offending some people,and hurting the project, so they got over themselves.

  6. Spot on! by idiotnot · · Score: 4, Insightful

    I've managed to compile and successfully run GNUMach and GNU/Hurd from CVS. I know my way around building code. But mplayer is still a pain in the ass. Seriously. And when I read the forums, I didn't dare ask a question. The developers' attitudes represent one of the most valid criticisms of the Free Software world -- support is fleeting.

    As for using the software, it works pretty well, and has steadily improved. But I don't build it anymore -- I use the unofficial debian packages, and they work pretty much flawlessly.

    1. Re:Spot on! by lobsterGun · · Score: 4, Funny

      You just need to know how to ask. The trick is to phrase your question in such a way as to insult the dev team, that way they feel a duty to defend their project (This actually works on any open source project).

      Example: You are having trouble with 'foo'.

      Wrong way to ask for help:
      You ask - "Could someone please help me get foo working?"

      They answer - "STFU n00b!" -or- "Read the FAQ n00b!"

      Right Way to ask for help:
      You post - "This application sucks. Foo doesn't work worth a damn"

      They answer - "Dood! you're probably forgetting to compile with the -Dl337 flag. If that doesn't work email me at progMan@hotmail.com"

      Simple enough?

    2. Re:Spot on! by 0x0d0a · · Score: 4, Interesting

      More seriously, there *is* a wrong and right way.

      Ask a specific question. If you say "Can someone help me to get X working...", you're going to get a "no". Why? Think of what you actually just asked -- you, one of zillions of people, just said "will you commit an unknown amount of time to providing me with support for free".

      If you say "When I run foo, I get a 'RTC support not included' error. What can I do to fix this?", and you *checked* the documentation and google first, then you're likely to have a lot more luck, because the other folks can immediately respond with an answer. They just can't *do* anything with a "it doesn't work" post, and most folks are not interested in investing the time require to send out another post with a list of what information is required so that perhaps they can get a response back so that perhaps they can fix a random person's problem. You need to send out a post with enough information to allow the folks you're asking for help to answer your question without immediately needing to ask you for even more information.

      This is no different from free support for closed-source software. You'll get the same response on USENET if asking a question about Half-Life. If you're paying someone to sit on the phone and answer questions (like someone at Microsoft with an MSDN support incident, or someone at Red Hat with a commercial support package), *then* things may be different.

      It's not just a matter of *insulting* the other person -- you need to include enough information to let them do your request.

  7. Don't flame the devs by arvindn · · Score: 5, Insightful


    Doesn't the author understand how the Linux/OSS community works, or what? Its not the devs' job to make shiny installation druids that you can click through. That's what distros are for. If you want to compile software, be prepared to do your homework. If not wait for the .deb to become available or subscribe to RedHat network etc.

    Gimme a break.

    1. Re:Don't flame the devs by pgrdsl · · Score: 5, Insightful
      Once upon a time, many years ago, free software was wild and untamed. When you downloaded a tar-file, it may, or may not, unpack in ".". Sometimes it was a shar(k) and you had to hope it didn't eat any of your files when you ran it.

      And then, once you had your nice shiny sources, you could compile it. After, of course, hand editing the Makefile. Oh, and the other one. And, damn, that silly config file. And then you would fix all the compilation problems because it had been developed on a different version of Unix, and used strdup.

      But, in those days, men were real men, and hackers were real hackers.

      People complained, whinged, sent patches, and things improved.

      And then, miracle of miracle, automated configure and build scripts came. There was the perl one, which asked lots of questions that nobody ever knew the answers to. Then there was the GNU configure scripts, which tried out things and found what worked.

      And, yea!, verily, time was saved all round the world. Things started to work. Porting to other platforms became simpler. Installation was tamed, and things went were you expected them to.

      What I'm trying to get at is: the same argument about "be prepared to do your homework" was used years ago pre-autoconf. Nobody would even think of going back to hand-editing all those Makefiles.

      It doesn't take a vast amount of effort to get a sane build and installation process, and the amount of time it saves everyone (including the developers themselves) is massive.

      With distros it is less of an issue for mere mortals, but the benefit any open source project will get from being easy to configure and install is that developers who are willing to chase bugs will do so - because it takes no pain to build.

  8. well, give VLC a try by Sam+H · · Score: 4, Informative

    VLC from VideoLAN accepts almost all the formats MPlayer groks. The major exceptions are the ones for which there is no GPL-compatible implementation. It can also transcode streams into different formats, or send them to the network, serve them as HTTP, etc. It is truly cross-platform and the Windows and OS X ports are extremely popular.

    --
    God, root, what is difference ?
  9. A good GUI by er_col · · Score: 3, Informative

    For those of us who are less than happy about MPlayer's default GUI, there are far better alternatives, like KPlayer for KDE.

  10. Who is this doofus? by Ih8sG8s · · Score: 3, Insightful

    This guy's article is self congratulatory and self seeking. I don't care what run-ins he's had with the developers in the past.

    A terrible review where he actually admits to not really checking it out fully, but still manages to come to the self-affirming conclusion that he was right all along, and takes the opportunity to take a personal jab at the project.

    The only thing I learnt from this article is that the writer is bitter, and lacks tact.

  11. mPlayer powers Xbox Media Player and Center by seven5 · · Score: 4, Interesting

    WOO HOO for mPlayer. I remember back in the day trying to get that mutha to compile. It was a pain in the neck. But once i did it, i had VIDEO ON LINUX!!! WOW. Now it is used all over as underpinnings for other apps. Its projects like these that are so great. This is where i feel opensource shines. Instead of doing a lot of work yourself, take a project that is established and working, and extend it. Xbox media player and now Xbox media Center both use mPlayer. By using the source that was available to them, it increased time to live so to speak. It works great and supports TONS of formats. Why reinvent the wheel. Especially in video players and html renderers (KHTML, MOZ).......

  12. mplayer's option syntax annoys me by amoe · · Score: 4, Interesting

    Why did they pointlessly violate the established (and useful) double-dash for long options convention in favour of an ugly and irregular one dash for all options? I'm aware that it's probably an imitation of the X standard, but in this day and age that's probably not a good thing to imitate. Also, it doesn't allow you to abbreviate with one-character options.

    --
    You look beautiful! Incidentally, my favourite artist is Picasso.
  13. mplayer suid ?!?! by SpiritC · · Score: 3, Informative

    "... I made the Mplayer binary SUID and that helped. ..."
    i dunno why he would do that but if it is about RTC then a closer look to mplayer (excelent) documentation would show this:
    If you are running kernel 2.4.19pre8 or later you can adjust the maximum RTC frequency for normal users through the /proc filesystem. Use this command to enable RTC for normal users:

    echo 1024 > /proc/sys/dev/rtc/max-user-freq

    --
    Smile... tomorrow will be worse.
  14. Barr and bias by 0x0d0a · · Score: 4, Insightful

    Won't this seem daunting to the end user (labelled automatically as stupid), having two different applications, with individual libraries, for doing the exact same thing.

    No. Xine should be installed on systems intended for non-techie end users. Mplayer is not a particularly great choice for non-techies. A'rpi is very much opposed to the idea of binary distributions (since it means that things may run slightly slower on a given system), and Mplayer can support so many things that to set up everything required for full support during a build can take a long time. It's less bad than building GNOME or KDE, but it's definitely not an "rpm -Uvh" either.

    That being said, I use mplayer exclusively, and love it to death. It's keyboard controllable, can be used without one of those godawful "fake media player" UIs, is faster than anything else in existence, and has support for just about every interface and codec under the sun (that Open Source folks can get their hands on or reverse engineer). Those of you not familiar with Barr and A'rpi (the lead mplayer developer for a long time) should be aware that the two intensely dislike each other, and have flamed each other for ages. Regardless of how good Barr is in most areas (and this review seems pretty reasonable, saying that "mplayer ain't a great choice for Linux newbies", which is definitely true), keep in mind that he's quite likely to have some bias, as A'rpi does when talking about Barr on the mplayer website. I take both with a big, big grain of salt.

    Perhaps some collaboration between MPlayer and Xine should occur.

    It does. Of course, it's full of people flaming each other for not giving sufficient credit, but the two projects have shared a *ton* of code in the past, and is the only reason either of them are as good as they are.

  15. Re:Here we go again... by dasmegabyte · · Score: 4, Insightful

    His argument:
    "I am a user savvy enough to be running linux. I am bright enough to fix problems. And yet, it was not easy for me to install this application. Therefore, it will be even harder for somebody who is new to Linux."

    Your argument:
    "What an idiot! He should have read the acoryphal poorly laid out document! Things are easy if you do all the chores perscribed to you by developers with no talent for technical writing and different systems than you!"

    My argument:
    "RTFM is not a valid complaint. Windows software installs without a manual. It does not expect you to RENAME directories after installing things to get them to work. It does not expect you to KNOW what codecs you want to use and already have them downloaded. It allows somebody to do what they need to do before hacking the source code of the underlying software. Why can't linux software do this as well. Oh right. Because we're better than them."

    --
    Hey freaks: now you're ju
  16. Don't run SUID root! by jimbrewer · · Score: 4, Informative

    Do not run SUID root if there is any other way to get the desired performance. From: http://www.securityfocus.com/archive/1/339193 Severity: HIGH (if playing ASX streaming content) LOW (if playing only normal files) Description: A remotely exploitable buffer overflow vulnerability was found in MPlayer. A malicious host can craft a harmful ASX header, and trick MPlayer into executing arbitrary code upon parsing that header. MPlayer versions affected: MPlayer 0.90pre series MPlayer 0.90rc series MPlayer 0.90 MPlayer 0.91 MPlayer 1.0pre1 MPlayer versions unaffected: MPlayer releases before 0.90pre1 MPlayer 0.92 MPlayer HEAD CVS Notification status: Developers were notified on 2003.09.24 Fix was commited into HEAD CVS at 2003.09.25 02:36:36 CEST MPlayer 0.92 (vuln-fix-only release) was released on 2003.09.25 12:00:00 CEST Patch availability: A patch is available for all vulnerable versions. Suggested upgrading methods: MPlayer 1.0pre1 users should upgrade to latest CVS MPlayer 0.91 (and below) users should upgrade to 0.92 OR latest CVS MPlayer 0.92 is available for download. -- Gabucino MPlayer Core Team

  17. Missing links? by Clith · · Score: 3, Informative
    Why are there zero links to Mplayer in this submission? Or even in the (above-score-of-2) replies? Here are some links:
    MPlayer site
    MPlayer downloads
    MPlayer for Max OS X site
    MPlayer for Mac OS X downloads
    Hope this is helpful for someone.
    --
    [ReidNews]