Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Graphics Software

Mplayer Revisited 353

Posted by michael from the it-slices-it-dices dept.
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.
This discussion has been archived. No new comments can be posted.

Mplayer Revisited More

Mplayer Revisited

Comments Filter:

  • Great for OSX (Score:5, Informative)

    by truffle ( 37924 ) on Friday October 03, 2003 @08:59AM (#7122881) Homepage
    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!

    • Re:Great for OSX (Score:5, Informative)

      by Fred IV ( 587429 ) on Friday October 03, 2003 @09:04AM (#7122923)
      VLC [videolan.org] 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).

      • Re:Great for OSX (Score:2, Informative)

        by Anonymous Coward
        Strange, that it does not work on your iBook. I'm using mplayer on 466 MHz iBook and it works better than VLC - doesn't lose sync and is way faster.

      • Re:Great for OSX (Score:2, Informative)

        by a.deity ( 665042 )
        I've got the same iBook, and VLC works very well, with the exception of HQ DivX encodes. MPlayer OS X is a lifesaver then, as it seems to be a bit smoother. MPlayer's not full-time for me, though, since the lipsync sometimes falls out, which VLC avoids quite well. Is there an audio-sync function in MPlayer that I don't know about? Turning on the slow-media cache helps, but isn't a sure thing.
    • Yep, I like it too. The only two things that bothers me is
      • the fact that it takes up two dock icons and
      • when mplayer is already running and I doubleclick a movie in the finder, mplayer comes up to front, but in 80% of all cases it won't open and play the file, instead just sitting there.
      Anyway, it's free, and I like it. Pressing the left/right arrow keys to instantly jump back/forward 10 second absolutely rocks - I wished my physical DVD player had this feature :-)

  • What about other software? (Score:3, Flamebait)

    by Kandel ( 624601 ) on Friday October 03, 2003 @09:03AM (#7122918) Journal
    Sure, it's great to have a v1.0 release of MPlayer, but on the other end of the stick, Xine [xinehq.de] 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
    • Actually I really like diversity so having both xine and mplayer as separate projects is a very good thing.
      • In other words, spread all resources as thin as possible instead of making one big kick-ass killer app. All in the name of idealist "diversity."

        All that matters is net output. That's it.

        • In other words, spread all resources as thin as possible instead of making one big kick-ass killer app. All in the name of idealist "diversity."

          You assume that adding more people to this project will automatically make it a bigger, better "killer app". That is not at all obvious, given what we know about human nature.


          All that matters is net output. That's it.

          All that matters to *you* is net output. You can hardly fault the developers for not seeing it that way. They are happy to contribute their

        • Re:What about other software? (Score:4, Insightful)

          by Dave_bsr ( 520621 ) <slaphappysal@hotmail.com> on Friday October 03, 2003 @01:20PM (#7125474) Homepage Journal
          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*.

    • the fact I find most surprising, is that Microsoft hasn't stepped in argueing that the software cannot be called, "MPlayer"

      Microsoft's product is called "Media Player". MPLAYER.EXE is merely an antiquated, conventional, DOS-format file name.

    • Re:What about other software? (Score:4, Funny)

      by sewagemaster ( 466124 ) <sewagemaster&gmail,com> on Friday October 03, 2003 @09:20AM (#7123039) Homepage
      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!
    • aving two different applications, with individual libraries, for doing the exact same thing

      Gasp! There are two media players! Shocking! Seriously tho, what's wrong with that? It gives people choice!!

      If there ends up only being one way or program to do anything, then things start to resemble the way Microsoft do things.

    • Barr and bias (Score:5, Insightful)

      by 0x0d0a ( 568518 ) on Friday October 03, 2003 @10:25AM (#7123558) Journal
      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.

    • Re:What about other software? (Score:5, Insightful)

      by Qzukk ( 229616 ) on Friday October 03, 2003 @10:39AM (#7123722) Journal
      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.)

      • I wholeheartedly agree. choice gives both projects strength...

        Thanks for mentioning the -fs thing...why does it seem so simple to do those things when someone else mentions them on slashdot, rather than drudgin through manuals? ah well, my love for linux is continued, as you helped me learn something new today, thus keeping my daily streak alive.

    • emerge xine

      emerge mplayer

      Help, I'm confused!!

    • I don't consider your post "flamebait", but I have to disagree. Last weekend I fixed a bad partition table:
      1. sfdisk was the only utility to report the problem correctly (the partition table was inside the swap partition)
      2. fdisk was the only tool that would delete the incorrect partition
      3. parted was handy to recreate the swap partition avoiding the swap.

      They all do the same thing in principle. Although, you see ? Software diversity saved my ass :-)

  • Of course you were criticised! (Score:4, Funny)

    by 91degrees ( 207121 ) on Friday October 03, 2003 @09:04AM (#7122919) Journal
    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.

    • Re:Of course you were criticised! (Score:3, Insightful)

      by Anonymous Coward
      "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.
      • mplayer dvd://

        If you want to watch other titles on the DVD, use dvd://1, dvd://2, etc.

        MPlayer does *not* have DVD navigation support (as xine and ogle do), so if you're a DVD fan and using the DVD browser interface is important to you, you may want to not use mplayer with DVDs.

        If you want to use a nondefault audio track and subtitles, you'll need to specify them. I needed -aid and -sid to watch my new copy of Ghost In the Shell in Japanese with English subtitles, rather than the nasty ol' dubbed version

    • Re:Of course you were criticised! (Score:5, Insightful)

      by curne ( 133623 ) <curne&curnomatic,dk> on Friday October 03, 2003 @09:24AM (#7123061) Homepage
      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.
      • 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.

        Don't read those messages. Procmail them to /dev/null/. But don't write pissy documentation. That's just childish.

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Friday October 03, 2003 @09:42AM (#7123174)
      Comment removed based on user account deletion
      • 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)

        In the mplayer documentation, there's a section named users_against_developers.html. In it, Joe Barr is personally attacked. I would never bother filing a bug report on mplayer until I had compiled mplayer by hand and had a 10k example movie file that I had checked against the standards, not with that level of professionalism on the other end.

  • Why review only the beta version? (Score:5, Informative)

    by TheOrquithVagrant ( 582340 ) on Friday October 03, 2003 @09:06AM (#7122937)
    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.
    • The reviewer does acknowledge at the start that it is a pre-release.

      And yes, reviewing the full 1.0 would be better, but pre-release versions are supposed to give a good idea of what the release version will look like.

      It looks to me that he's found problems that are greater than what bugfixes will help. A prerelease should not have wholesale organizational problems in the software, heck, in my opinion, all the Windows betas I've seen are better than this.
    • Yes, it's a pre-release...
      Yes, Joe wrote a review based on it
      Joe liked it and was only disapointed by the install...which I agree, still sucks :)
    • It makes sense to review a pre-release, particularly if the review turns out to be nearly entirely favorable. Since his issue with the mplayer before was that it wasn't sufficiently polished for an end user to install, and the difference between a stable 0.n release and a 1.n release is normally assumed to be whether it had gotten to the point of being generally useable, it makes sense for him to look at whether it seems likely that 1.0 will meet this criterion.

      And it turns out that he finds it satisfactor

  • MPlayer has matured... (Score:5, Interesting)

    by Valar ( 167606 ) on Friday October 03, 2003 @09:09AM (#7122961)
    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.
    • Comment removed based on user account deletion
      • This build does not contain all available options in mplayer. There's no mga or xmga support (which I use), for instance. If you want the goodies, you have to do the build yourself.

  • Spot on! (Score:4, Insightful)

    by idiotnot ( 302133 ) <sean@757.org> on Friday October 03, 2003 @09:10AM (#7122967) Homepage Journal
    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.

    • Re:Spot on! (Score:5, Funny)

      by lobsterGun ( 415085 ) on Friday October 03, 2003 @09:41AM (#7123170)
      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?

      • Re:Spot on! (Score:5, Interesting)

        by 0x0d0a ( 568518 ) on Friday October 03, 2003 @10:41AM (#7123752) Journal
        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.

        • Re:Spot on! (Score:3, Informative)

          by fucksl4shd0t ( 630000 )

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

          While you did an excellent job summarizing the points, Eric S. Raymond wrote an article [catb.org] that I found particularly helpful, and after reading and putting into practice what he was saying (all of which made sense) i started getting a l


    • I don't get it. I compile/install mplayer often. ./configure autodetects everything except user preferences such as GUI support, LFS. What doesn't work when you enter ./configure && make && make install? There have been a lot of posts proclaiming mplayer's compile-time surrleyness, and I'd like to know what's wrong with it. Is it not finding your libraries and/or headers?

      Confused.

      Matthew
    • If you can successfully get GNU/Hurd from CVS up and running, installing MPlayer should be easy as pie.

      You only need a few things. MPlayer source. Win32 libs. Put win32 libs in /usr/lib/win32, extract MPlayer source, ./configure && make && make install. There are a couple extra libs you can compile mplayer against but they aren't necessary.

      It had some problems on old systems, pre gcc-2.95.3, other than that I have never seen any problems getting it up and running on any distro on any

  • Don't flame the devs (Score:5, Insightful)

    by arvindn ( 542080 ) on Friday October 03, 2003 @09:11AM (#7122981) Homepage Journal

    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.
    • "Its not the devs' job to make shiny installation druids that you can click through."

      If they want their software to gain popularity and more widespread usage, they will.

    • No you should flame the devs. Here is the simple math, for every problem that they leave in the finished product, the developers spend huge amounts of time wading through their mailbox and message boards with the same questions. So unless you are going to require that only developers download your code, the overall support equation says that you should cover your bases - make a resonable install, document cleanly and have some technical writers on your team.

      • Re:Don't flame the devs (Score:2, Insightful)

        by curne ( 133623 )
        A slight correction: Developers can flame other developers, since they can apreciate the problems involved.

        Idiot lusers who do not know the difference betweeen C and csh scripts should not flame developers since they will invariably make asses of themselves. They can flame the distro makers, who get paid for helping (or at least, the idiot lusers should pay them for the priveledge of flaming them).

        Geez, cant everyone just get along?
    • shiny installation druids

      Now that evokes an interesting image....

    • Re:Don't flame the devs (Score:5, Insightful)

      by pgrdsl ( 713039 ) on Friday October 03, 2003 @09:53AM (#7123284)
      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.

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

      The idea that a user should expect to be a guru and that the developer has no responsibilities towards the community is part of what prevents the open source community from a

    • Last time I checked, packaging MPlayer had major license problems. I believe at some time it was not even allowed to package according to a clause in the MPlayer license.

      But even now there are problems because of all the libraries which are not in the GPL or any other Free Software license. And this is a problem mainly for Debian which has pretty rigid license terms.

      Just checked and yes, there are still issues. See http://www.mplayerhq.hu/homepage/design6/news.html #debianandsusesux [mplayerhq.hu].

  • A good GUI (Score:3, Informative)

    by er_col ( 664618 ) on Friday October 03, 2003 @09:25AM (#7123075)
    For those of us who are less than happy about MPlayer's default GUI, there are far better alternatives, like KPlayer [sourceforge.net] for KDE.

  • Who is this doofus? (Score:3, Insightful)

    by Ih8sG8s ( 4112 ) on Friday October 03, 2003 @09:26AM (#7123076)
    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.

  • Were the copyright violations fixed? (yet?) (Score:3, Insightful)

    by ciaran_o_riordan ( 662132 ) on Friday October 03, 2003 @09:29AM (#7123105) Homepage
    The problem I heard about MPlayer was that it illegaly contained DivX code that was under a proprietary license.

    Last time I checked was two months ago and MPlayer was still in violation of DivX copyrights. No distro can distribute it as the developer releases it. This is the real problem. This pushes it from Free Software to "cracked warez".

    (SuSE, and maybe others, do distribute it but they rip out the illegal code, so it's missing a few codecs. Debian will also be shipping a stripped, legal version soon.)

    Ciaran O'Riordan

    • Re:Were the copyright violations fixed? (yet?) (Score:2, Informative)

      by Anonymous Coward
      Please, pretty please, before you talk about something you know nothing about, get your facts straight.

      MPlayer currently doesn't contain single line owned by DivX networks. None. Nada. (In past, they used opendivx, and while it was under opensource license, it was neither GPL compatible nor free software).

      Nowadays, MPlayer uses libavcodec library from ffmpeg project. It it fully LGPL library, you can find it on sourceforge. The reason that SUSE rips it out is simple - some algorithms are patented (please
      • If it infringes a patent that is not licensed for zero-cost use, it cannot be distributed under the GPL.

        GPL, section 7:
        "If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all."

        I asked a question and gave the basis for my question. The ffmpeg library does infringe a patent. The patent has not been enforced for decoding before, but that doesn't mean it will not be enfo
    • Debian will also be shipping a stripped, legal version soon.)

      Or just throw this in your sources list in the mean time:
      deb http://marillat.free.fr unstable main
      I would imagine Debian would official throw it into non-free or provide some kind of wrapper script to go out and download the codecs in question.

    • Nevermind the fact that in the US and other countries that recognize pure software patents, it's illegal to use GPL'd MP3 based software. Since the GPL allows commercial use of software under it's license, and Fraunhoffer prohibits that without paying them first...

    • Illegal distribution of Win32 codecs (Score:2, Interesting)

      by Anonymous Coward
      The Mplayer project's distribution of copyrighted win32 codecs is illegal.

      One needs explicit permission from the copyright holder to distribute copyrighted works.

      The Mplayer project does not have such permission from Apple, Microsoft and Real.

      The codecs are available for free (as in beer) from their respective owners, but the included EULAs do not grant permission to redistribute.

      It is obvious why Mplayer has yet to be accepted by Debian. The Mplayer team has no respect for copyright law and continues t
    • Woudn't mplayer have to dump dvd support to come completely clean? I'd rather keep it the way it is. Not because I'm a crook, but I'd rather copy DVDs to my laptop's harddrive and use the drive bay to hold an extra battery when I fly... so shoot me.

  • Don't forget movix, the bootable mplayer (Score:3, Informative)

    by elwinc ( 663074 ) on Friday October 03, 2003 @09:30AM (#7123110)
    If you're a fan of mplayer, you might want to check out MoviX [sourceforge.net] which makes bootable mplayer distributions. My favorite variation is MoviX^2. You boot from the movix2 CD, eject the movix2 CD, pop in a CD or DVD with any mplayer supported format, and there you go!
  • maybe its better to pitch in and help write the documentation for the project than to lambaste the devs for poor documentation. Regardless, its available precompiled on nearly any distro. Worked fine on Slackware 9.1 by going to linuxpackages.net (the home of all slack packages) downloading, and rning instllpkg mplayerx...

  • mPlayer powers Xbox Media Player and Center (Score:4, Interesting)

    by seven5 ( 596044 ) on Friday October 03, 2003 @09:44AM (#7123197)
    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).......
  • Funnily enough I installed 1.0prewhatever last night.

    I downloaded the source, typed ./configure
    make
    su -c "make install"

    And I was done.
    (I didn't bother downloading any skins or anything posh like that. CLIs are good enough for the likes of me.)

    Mind you, that was on Slackware 9. But even so, I think yon reviewer may be taking the piss a bit. Why did he expect a CVS build to work as cleanly as an official one. Isn't the point of a CVS version being available so people can see and help with a work in progres

    • doh (Score:2)

      by K. ( 10774 )
      Forgot the "and then I copied the codecs into the appropriate directory" stage, but that wasn't exactly rocket science.

    • Re:difficult my arse. (Score:3, Informative)

      by parabyte ( 61793 )
      Even more funny, I did the same thing last night on a Out-Of-the-Box SuSE 8.2 System; I just had to remove the useless crippled mplayer that comes with SuSE.

      At first I was a bit scared by all this stuff about installing additional codecs in the documentation, and I even downloaded ffmpeg because I follwed the documentation step by step, but later I found out it applies to the cvs checkout only, is already included in the release tarballs.

      The fact is: for most cases, the included ffmpeg and other included
  • Gentoo makes the installation completely painless, although configuration can sometimes be a pain in the ass. I'm happier editing config files than dealing with make, though.

    With all the complains about the GUI setup, you'd think there'd be more people using the completely painless command line version:

    mplayer
    (file magically works perfectly)

    I watch my videos in fullscreen anyway, so GUIs just get in the way. The only thing they seem to add is random seek, which is a useful feature, but not what people s

  • mplayer's option syntax annoys me (Score:4, Interesting)

    by amoe ( 550586 ) on Friday October 03, 2003 @09:58AM (#7123334) Homepage

    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.

    • want a dvd? You need to use the "dvd" URL

      dvd://title#

      But this syntax

      dvd://title#/chapter#

      Doesn't work, you need this:
      dvd://title# -chapter chapter#

      Which is more typing than: -dvd title# -chapter chapter#

      And filters for -vop are applied IN REVERSE ORDER.

      How about this malarky:

      -vop detc=dr=1:ar=0,denoise3d

      commas distribute over colon, colon over equals, except for the first equals that shows a filter has options.

      urrggghh...

      Oh, and the syntax is horrible just in general. Some options only take effec
  • It seems that a lot of the innovative "best of breed" open source projects are run by utter assholes: Mplayer, Qmail, OpenBSD, etc.

    I suspect that it's not coincidence. Building concensus and playing well with others means making compromises. Compromises are the enemy of innovation. It's the people who take their ball and go home who crack the mold. They go off in "unprofitable" directions. Most of them labor in obscurity. A few of them turn out to be right and manage to produce something useful.

  • mplayer suid ?!?! (Score:3, Informative)

    by SpiritC ( 163392 ) on Friday October 03, 2003 @10:04AM (#7123393) Homepage
    "... 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
  • yum install mplayer

    That's all it takes. I installed yum from FreshRPMs [freshrpms.net], and no configuration was required.

    If you issue the following two commands:

    1. chkconfig yum on
    2. service yum start

    then any software you have installed will be kept up-to-date automatically, every night. It doesn't have to be hard to use Linux. Why do people insist on making it appear harder than it is? To frighten noobies?

  • I prefer the idea of gstreamer [gstreamer.net] ...
    you define a graph to play your content. You can even describe the graph on the command line ;-).
    mplayer uses Windows DLLs - yuck.
    Just one problem ... when I tried gstreamer and mplayer last month (on RedHat 9) mplayer worked much better. For example, gstreamer claimed to play Quicktime but didn't. I know I was in trouble when gst-launch-ext (sp?) -- the script that plays files based on their extensions -- said .mov was invalid!

  • Don't run SUID root! (Score:4, Informative)

    by jimbrewer ( 681104 ) on Friday October 03, 2003 @10:49AM (#7123841)
    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

  • GUI Look (Score:2)

    by Alan ( 347 )
    Sadly both xine and mplayer have horrible GUIs by default. Totem on the other hand, which uses the xine libs for it's video playback, has a nice clean GUI that is actually usable. Personally I use mplayer from the command line out of habit, but the lack of a gui that doesn't suck would be a nice option.... I think even jwz ranted about this some time back /me puts on mod-proof undies
  • What's the best way to watch DVDs? Do any distros even support this out of the box? Presumably they would have ship with DeCSS. I tried to get playback working under Mandrake 9.1 the other day, and after several frustrating hours I ended up with something that couldn't even match Windows 4 years ago. It requires adding in the PLF sources, but the latest version of the Xine player didn't seem to have all the packages available; VLC worked, but kept dying silently (core dump?); MPlayer seemed to require t
  • For Mandrake 9.1, it was a simple matter of "urpmi mplayer" to get the basic MPlayer installed. Finding the Windows DLLs so MPlayer could play Sorenson QuickTime files (and presumably others) was harder, but doable through Google. Installing them so MPlayer could use them was reasonably easy (create /usr/lib/win32 and copy the DLLs there), though adding an import function to the GUI that would automatically extract and copy the files would have been better for the less technical users .

    For those of us wh

  • Missing links? (Score:3, Informative)

    by Clith ( 5063 ) * <rae@tnir.org> on Friday October 03, 2003 @11:18AM (#7124153) Homepage Journal
    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 [mplayerhq.hu]
    MPlayer downloads [mplayerhq.hu]
    MPlayer for Max OS X site [sourceforge.net]
    MPlayer for Mac OS X downloads [sourceforge.net]
    Hope this is helpful for someone.

  • OS X (Score:2)

    by jafac ( 1449 )
    On OS X MPlayer is about the only media player that will balls-out play just anything. Bottom line, this is what it's all about. That's the killer-app of video as far as I'm concerned. The program that does not make it the user's concern what format, what encoding method, or who copyrighted what. Don't hassle me with technical crap. When I want that, I'll open a term window. But when I'm going throug video clips, I certainly don't need that kind of hassle. (often, my right hand is covered with lotion
  • emerge mplayer Wow. that was tough. I think I need a beer and a pizza to help recuperate after such a trying ordeal.

  • My own "review" of mplayer/mencoder (Score:3, Interesting)

    by Dr.Dubious DDQ ( 11968 ) on Friday October 03, 2003 @03:22PM (#7126820) Homepage

    In short form...

    Pros:

    • Probably supports more formats and codecs than just about any other project (on just about any other platform). Though typing "mplayer /dev/random" and having it show me "Return of the King" doesn't QUITE work yet...
    • Has a HUGE array of features
    • configure script for compilation is surprisingly 'smart' about picking options for optimal operation
    • LOTS of documentation online
    • error messages are often quite informative. (I've gotten used to terse "Unable to Conflugalize the Blurglemeister. Aborting." messages, where MPlayer tends to instead say things like "Could not Conflugalize the Blurglemeister. This could be due to too slow of a CPU or insufficient memory. Try again with -no-conflugalize or -framedrop")
    • huge range of potential uses, beyond 'playing videos' (exporting to external encoders, rendering subtitles, postprocessing video, correcting framerates, etc. etc.)
    • "Cross-pollinates" with other projects, most notably FFMPeg(/libavcodec) [sourceforge.net] and Xine [sourceforge.net].

    Cons:

    • Parameter syntax is somewhat non-standard
    • Sometimes hard to figure out which option to use for a specific process
    • a few holes in the documentation (e.g. details of what some of the postprocessing filters do and what the parameters for them mean, exactly)
    • Mencoder only supports .avi output (or .mpg, but this is experimental)
    • Can't 'directly' create (S)VCD-compliant video at this time (but there are scripts for doing so using mplayer and mpeg2enc/mp2enc)
    • Some options are inconsistent between mencoder and mplayer (e.g. -ofps ["adjust the framerate by copying or dropping frames"] exists in mencoder but not mplayer)

    Maybe a Pro, maybe a Con:

    • It has a GUI, but the GUI is something of an 'afterthought'. (The fact that a GUI exists is probably part of the reason so many people assume mplayer is intended to be a 'general user' program. MPlayer might be better off not even having one. On the other hand, choice is good.)
    • Can use Windows codecs for many formats that aren't 'natively' supported (complicates distribution issues and only works on i386 platforms, but at least provides a 'fallback' method for viewing some otherwise-unviewable files)
    • Is NOT a project focussed on 'end-user' applications. (From my perspective, this is why it has so much functionality - the developers 'waste' little time "making it look pretty" or "so simple even an idiot can use it", but it gets them subjected to a lot of abuse from people who resent those lacks. I worry that the abuse will discourage developers from doing anything...)
    • So many features it's hard to tell sometimes what you can and can't do with it...

    I find it interesting, incidentally, that MPlayer supports Ogg Theora better than XIPH does at the moment, in my opinion....(mplayer actually does play back Ogg Theora files generated by the Theora CVS quite nicely. Now if only Xiph would ever work on Ogg Theora and the Ogg specification again...)

Slashdot Top Deals

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Close