Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Media Movies

MPlayer 0.90 released; MPlayer Maintainer Leaves 338

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

MPlayer 0.90 released; MPlayer Maintainer Leaves More

MPlayer 0.90 released; MPlayer Maintainer Leaves

Comments Filter:

  • Wha? (Score:4, Funny)

    by evilviper ( 135110 ) on Tuesday April 08, 2003 @05:13AM (#5684963) Journal
    I'm in shock! No Mplayer-pre576 !

  • fp? (Score:2, Offtopic)

    by Lispy ( 136512 )
    MPlayer is very promising though controverse project. Lets see what it all boils down too after the reconstruction...I use it and like it.

  • Congrats to the MPlayer team! (Score:5, Interesting)

    by Longinus ( 601448 ) on Tuesday April 08, 2003 @05:18AM (#5684976) Homepage
    .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 [kernel.org], 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.
    • it's always nice to have examples of open source software that so readily stomps into irrelevance its closed source competition

      By using closed source binary codecs stolen from proprietary closed source programs?

      • Or would you prefer we were all MSN Subscribers rather than Internet Citizens?

        • Re:yes, exactly because of that (Score:4, Insightful)

          by October_30th ( 531777 ) on Tuesday April 08, 2003 @05:37AM (#5685013) Homepage Journal
          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?

          • Re:yes, exactly because of that (Score:4, Informative)

            by Longinus ( 601448 ) on Tuesday April 08, 2003 @05:42AM (#5685032) Homepage
            "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.
          • Prome is sometimes using the right tool for the jobs hampers and alter the path and progress other projects can make. If nobody feels the need for a good native decoder then progress will be slower, and Microsoft may sue / whatever and you are left with neither ham nor sausages.

            You have to think of the hidden risks of every action. You need to take into account all the pros and cons. Of course it's better to just not care and use the win32 binaries. Nobody will complain now, but some time from now we may,

      • Re:Congrats to the MPlayer team! (Score:5, Informative)

        by Longinus ( 601448 ) on Tuesday April 08, 2003 @05:32AM (#5685001) Homepage
        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.
        • Low CPU usage is an understatement. I can play fabulous looking video in almost any format with no more than around 2% CPU usage on my Athlon 1400. It's very well designed. Just give it a good video card with appropriate XV support, and it flies. And it's got to be the most stable player out there.

          A'rpi, thanks for all of the work that you've done. I'm sorry that you've missed out on a lot of free time, but your work is deeply appreciated by many. You've helped take the frustration out of Linux video

      • Re:Please (Score:3, Insightful)

        by ErikJson ( 27997 )
        Yes. And we love it!

        Seriously, ofcourse it had been better to do it in some other way, but what do you propose?

      • Re:Congrats to the MPlayer team! (Score:5, Insightful)

        by vandan ( 151516 ) on Tuesday April 08, 2003 @05:41AM (#5685027) Homepage
        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.

        • Re:Congrats to the MPlayer team! (Score:4, Insightful)

          by YrWrstNtmr ( 564987 ) on Tuesday April 08, 2003 @08:15AM (#5685494)
          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.

          So what you're saying is, that it's ok to cuddle up to software from the EvilOne(tm) as long as naked chicks look ok on your screen, ideals be damned.

        • Re:Congrats to the MPlayer team! (Score:4, Insightful)

          by Kourino ( 206616 ) on Tuesday April 08, 2003 @09:19AM (#5685819) Homepage

          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.

          Wrong. Most of my computers can't run Windows binaries. (In fact, the computer I've come to use the most runs a PowerPC 750.) After all, not all the world's an x86. I'll take my native decoder, thanks. That way I can actually watch stuff.

      • Re:Congrats to the MPlayer team! (Score:4, Interesting)

        by Kourino ( 206616 ) on Tuesday April 08, 2003 @07:52AM (#5685393) Homepage
        ... that only work on one platform? It still annoys me greatly that mplayer runs extremely well on my Pentium 3, but, depending on the task, absolutely crawls on comparable hardware from other architectures, or just plain doesn't support stuff at all.

        mplayer? Plays everything? You obviously don't use powerpc-*-linux or alpha-*-linux :3
      • I know I'm feeding the troll here, but...

        How can you "steal" a codec that's given away for free? Just because it was used in a non-windows setting means they stole the codec? Granted some of the early DivX codecs were of dubious origin, but they were used in Windows as well, and nobody uses those anymore anyway (except in Windows).

        Mplayer does what every good windows player (including mplayer2.exe) does, it incorperates as many codecs as possible from as many free sources as possible. Mplayer does ma
      • ...using those closedsource binary decoders is out of necessity. Inventing a codec JUST so that you can implement it in proprietary software, and keep open-implementers at bay (in order to sell your dubious wares) is not exactly a moral victory.

        Until the business model for Closed Media Formats disappears (by mplayer making making the decoder work everywhere (therefore no different than OPEN standards (so they loose the ability to differentiate))) im all for mplayer using those binary files.

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

      Not trying to bash mplayer or anything, I used for quite some time, but how about Xine [sf.net] ? I switched over a few months back and I've been more than happy with that.

      I think the approach in Xine is more *nixy like with the marvellous lib and multiple UIs. But that's just my 2 cents...

  • THANKS ARPI! (Score:4, Insightful)

    by Anonymous Coward on Tuesday April 08, 2003 @05:19AM (#5684977)
    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!

    • Re:THANKS ARPI! (Score:5, Informative)

      by den_erpel ( 140080 ) on Tuesday April 08, 2003 @05:29AM (#5684997) Homepage Journal
      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...

      • sync issues (Score:2, Informative)

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

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

        It even makes files that play correctly play more smoothly.
        • mplayer, memcoder and transcode crash all on files where the audio video sync is terrible. I am not talking about 100 frames/samples, but about a 1,000 or more.

          I had a number of such (nuppel) files, and wouldn't care if the quality of the audio was bad, as long as I had the files trancoded (the problem occurred in the first 1/5 of the file, the rest was perfect).

          mplayer, mencoder, transcode all segfaulted (I assume some buffer which never should be filled, got filled anyway).

          It has been a couple of month
      • 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 thought transcode used mplayer's shared post proc library too. Did they finally implement this on their own?
    • > You brought us the Microsoft ASF fileformat support

      Wasn't that actually the libavifile [sourceforge.net] guys...

    • Here, here!!! Without a doubt, MPlayer is the most complete media player available on ANY platform and, yes, that includes Windows. I hope somebody as dedicated as Arp'i steps in to fill his shoes!

  • MPlayer rules... (Score:3, Insightful)

    by Anonymous Coward on Tuesday April 08, 2003 @05:20AM (#5684980)
    ...they should turn the entire core into a lib and leave the whole GUI and frontend stuff to ppl who have time to waste with GUI and frontend development.

    MPlayer is so cool.. they dont need to write their own GUI...

  • well (Score:4, Informative)

    by daserver ( 524964 ) on Tuesday April 08, 2003 @05:21AM (#5684983) Homepage
    Well Arpi is still there on the mailinglist doing stuff, he's just not the maintainer any longer.

  • Sound so familar (Score:3, Interesting)

    by jsse ( 254124 ) on Tuesday April 08, 2003 @05:26AM (#5684988) Homepage Journal
    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.

    wait a minute, why this sound so familiar?.....

    Oh! Micro*shot*

  • Windows port? (Score:2, Interesting)

    by Majin Bubu ( 455010 )
    How about a Windows port of MPlayer? I know there are a lot of great players for Win, but I'd love to get rid of the *many* programs I need to play the various formats under Windows.
    Uh, please, don't suggest using Linux, I already do, I am a dual-booter, I just want something like MPlayer under Win as well.

  • Embedded Mplayer (Score:5, Informative)

    by mrsev ( 664367 ) <mrsev@ELIOTspymac.com minus poet> on Tuesday April 08, 2003 @05:32AM (#5685000)
    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.

  • will it lose the race against xine? (Score:5, Informative)

    by Pivot ( 4465 ) on Tuesday April 08, 2003 @05:35AM (#5685010)
    From his second posting;
    > IMHO mplayer is good enough now that it won't lost in /dev/null if i leave.

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

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

    • I don't think this is fair. I seem to remember that it was the Xine guys who worked out the SVQ1 format...
    • The trueness. I use Xine because it has an easy GUI, it plays all types of files well without me having to do anything special. It comes with my distro. Oh yeah, it has a GUI.

      This is a public service announement. There are two types of open source projects out there. The first kind is the kind where someone will write software for themselves and share the source to be nice and help others. The other kind is where someone writes software they want lots of other people to use and they develop it using the o

      • On the subject of GUI (Score:3, Interesting)

        by HuguesT ( 84078 )
        Hi,

        You write:

        > The other kind is where someone writes software
        > they want lots of other people to use and they
        > develop it using the open source model.
        > If you are making the second kind of software
        > you need to make a gui.

        Indeed I'm often reminded of the stunning GUIs associated with gcc, samba, apache and the Linux kernel.

    • Ah, but this is the beauty of Free Software. Xine did not steal. They re-used code under the terms of the MPlayer license.
      If both packages had been proprietary then we'd have two players. One with a sucky UI, and one with sparse codec support.
      MPlayer has not lost. Everyone who wants to use or develop a Free media player have won.
    • 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). F

  • Hope this project doesn't fall by the way side (Score:3, Funny)

    by sneakybilly ( 537969 ) on Tuesday April 08, 2003 @05:40AM (#5685022)
    This is by far the best Linux Media Player out. Plays all my pr0n :)

  • Idea for a new media player (Score:4, Insightful)

    by evilviper ( 135110 ) on Tuesday April 08, 2003 @05:42AM (#5685029) Journal
    Strangely enough, each thread I comment on, seems to lead into a discussion relevant to a story not-yet-posted.

    http://slashdot.org/comments.pl?sid=59962&thresh ol d=3&commentsort=0&tid=188&mode=nested&cid=5684 779

    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.

    A media player on Linux, Windows, Mac, or even a hardware device, could all use the same plugin, which you can store along with your media file if you like.

    The only thing that would have to be done for each platform, is to build a user interface, and write the native input/output calls. Sure, that's not so simple, but so much work is going into the codecs, that such a system would greatly simplify things. Just think, a Windows user could write a plugin for his video player, which you could then just copy over to your plugin folder, and play the same format.

    One stiplation, it is very unlikely embedded developers will adopt a piece of software if it is under a license more restrictive than the BSD, so a reference implimentation would have to be BSD licensed. (The folks at Xiph.org understood that)
    • The GStreamer [gstreamer.net] project aimed to do this and xine already has support for demuxer, codec, output, etc plugins (indeed all the DVD features used by xine used to exist as a totally separate project at dvd.sf.net).
    • 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-ind
    • A media player is much more useful if you don't have to recompile it to add support for one more format.

      Because new formats hit the market... Um... Maybe once a year?

      If there was a system-independent plugin mechanism

      There would also be no system dependant optimizations.

      there wouldn't be so much redundant work, with everyone doing the same things from scratch, for each player, and on each platform.

      The work is in figuring out how a file format works and how to decode it at fast as possible with th

  • MPlayer rocks! (Score:2, Informative)

    by cdemon6 ( 443233 )
    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...

  • Gstreamer (and xine?) (Score:2, Interesting)

    by KeyserDK ( 301544 )
    I think a projects like gstreamer has far more future than mplayer. It's true that mplayer has far more codec support, but what is really needed is a multimedia architecture, such as gstreamer.

    This is one important step getting linux closer to the desktop.

    • Re:Gstreamer (and xine?) (Score:5, Insightful)

      by groomed ( 202061 ) on Tuesday April 08, 2003 @07:27AM (#5685280)
      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.

    • Oh Please! (Score:4, Insightful)

      by Fefe ( 6964 ) on Tuesday April 08, 2003 @09:10AM (#5685778) Homepage
      Sheesh, people like you make Linux look more and more like Windows.

      "No, we don't need functionality, we need a framework!" (add "distributed", "real-time", "platform-independent" or "byte-code" to enhance the buzziness)

      "No, we don't need functionality, we need a pretty GUI!"

      "No, we don't need functionality, we need XML support!"

      I was able to build an embedded video playing machine using mplayer and Linux on a VIA C3 box in just 8 Megs of boot image size! Forget all that framework and XML and X and GUI and Gtk bullshit. You can stick your GNOME and ORBit where the sun don't shine. I just want to view movies on my machine, without your framework mania forcing me to install 3.1415e926 dependency packages first.

      That is the reason why mplayer rules by such a margin: it doesn't need fifty trillion packages which add no real value to the application itself.

  • Maybe we'll finally get some threading (Score:5, Interesting)

    by sanemind ( 155251 ) on Tuesday April 08, 2003 @06:00AM (#5685074) Homepage
    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.
    • I've wondered about this before as well, also having an SMP system running Linux. I'd like maybe a compile time option for threading (in the main code branch) so we could have threading while single processor users wouldn't be burdened by the context switch overhead. Thread safety now can also be useful down the line when Mplayer evolves a bit.
    • 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!

  • A'rpi ? (Score:3, Funny)

    by dnaumov ( 453672 ) on Tuesday April 08, 2003 @06:04AM (#5685084)
    "How do I..." "RTFM IDIOT!!!11"

    You mean THAT A'rpi ?

    • Re:A'rpi ? (Score:5, Insightful)

      by Anonymous Coward on Tuesday April 08, 2003 @07:36AM (#5685316)
      "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.
      • Anonymous Coward has a good point. People usually blame open source developers for being "elitists" but don't understand HOW and WHY they got that attitude in the first place.
      • Looks like someone is suffering from The Leet Disease [slashdot.org].

        I don't think that projects like this need separate PR people...I think people in the community need an attitude adjustment. Every n00b you blow off with "man man", "RTFM," "STFI," or any of those other lovely turns of phrase will be a n00b running back into the waiting arms of Microsoft. Because Microsoft understands that not only gurus use their software. Actually I'd prefer that the n00bs go running to Apple, because that's truly an example of a Rea

    • I suppose that now MPlayer versions will get boring names... who else could name 0.90 version "The RTFMCounter"?

  • developers attitude... (Score:4, Insightful)

    by erroneus ( 253617 ) on Tuesday April 08, 2003 @06:10AM (#5685090) Homepage
    ...I had joined the mailing list and the beginning of every message is "RTFM." It's quite insulting they'd think this incomplete project has complete documentation and answers every question.

    I had mentioned, as a user, things that should be addressed and they kept saying things like "use the CLI" for that. Utterly ridiculous.

    I am hopeful that someone will step up and guide development. Actually, I'd do it myself if I thought people would listen to me. I am not a developer and I think that'd be reason enough to disqualify me.

    I hope these things improve... it's a good project.

    • Re:developers attitude... (Score:3, Insightful)

      by BJH ( 11355 )
      they kept saying things like "use the CLI" for that. Utterly ridiculous.

      Hardly. It's common for a project with both a CLI and a GUI to have more functionality available via the CLI - it's just so much easier to add an extra option to the command line than to screw around with whatever graphical toolkit is being used for the GUI.

    • Oh come on... (Score:4, Informative)

      by Replicant7 ( 530766 ) on Tuesday April 08, 2003 @08:58AM (#5685703)
      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...
  • It would have been a far more useful release had it been made 2 months ago, as we've had the top linux distros all release new versions in the last month or so.

    Easy to say that in hindsight, sure, but it may mean that people who were using mplayer will switch to Xine in the latest distro releases.

    I've switched to Xine with the latest release of Mandrake I'm testing, except for DVD movies, which I use mplayer for, starting it with a shell script - mplayer is just so damn fine at playing DVD's (with a bit of timing tweaking)
  • It takes a lot of time and energy to run a project of any kind, and everyone should commend those that are able too..

    Even if they cant do it forvever..
  • Does anybody know how to play non-DVD subtitles with an AVI? I have a japanese movie with subtitles in a file apart and only with -sub it does not work.

    Ok, I have RTFM and know this is not the best place in the world to ask for it. But hey, I'm desperate :))
    • 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

  • Thank You from OS X users (Score:3, Interesting)

    by Loco3KGT ( 141999 ) on Tuesday April 08, 2003 @08:05AM (#5685439)
    Because Quicktime won't play 1/2 the stuff you do. And Windows Media Player for Mac is just as bad. I use mplayer for *everything* thanks to you (and fink).

  • So much hostility... (Score:4, Insightful)

    by entrigant ( 233266 ) on Tuesday April 08, 2003 @08:19AM (#5685514)
    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
    • Hmm. What you say is true. There has to be a line drawn somewhere, beyond which you give up on the user being unable to RTFM. However in the case of mplayer, the developer is a spoiled four year old brat as well. Here's a direct quote:

      "Unfortunately MPlayer is out of our control. It's used by lamers, Linux users who can't even use Windows, and never tried to compile a kernel."

      Call that tech support? 'If you can't compile a kernel, you're not WORTHY of our player.'

      I've not had any problems with mplayer--i
      • 'If you can't compile a kernel, ... or read the DOCS ... you're not WORTHY of our player.'

        What I'm trying to say is simple. I first used MPlayer in it's very earliest days (0.12?). I was a near total newbie to linux, and actually, this was about the first program I compiled under it. When I went to download it, they prominently said "Read the DOCS" it tells you how to compile it and we're not gonna help you if you don't. So I took that seriously and I read the DOCS. And guess what? It compiled fine,

  • Xine vs Mplayer (Score:4, Insightful)

    by realnowhereman ( 263389 ) <andyparkins@@@gmail...com> on Tuesday April 08, 2003 @09:11AM (#5685782)
    Not wanting to be objectionable ... but ... i've actually found mplayer to be slower than xine. I've got both on my 500MHZ K6-2 laptop and I can (just about) watch a DVD with xine. With Mplayer the CPU pegs and i get frame drops. To be fair I didn't try very hard to make mplayer work; but then again neither did I try very hard to make xine work. Anyone got any idea why this would be? I assume that I am incorrect in my assesment that xine is faster as the oft reported benefit of mplayer is its incredible speed...

    Xine recently seems to have taken a few leaps and bounds as well. The DVD nav stuff is working very nicely. There are a lot less crashes, the GUI is a lot more stable.

    I doubt whether competition is a bad thing anyway. At all other times in the OSS world competition has been beneficial, not least because they can steal each others code.
    • Xine recently seems to have taken a few leaps and bounds as well.

      The only reason..ONLY reason xine seems to have taken so many leaps and bounds is because the mplayer developer spend all thier time making sure stuff plays. The xine developers are more than happy to let the mplayer developers do that while xine works on the GUI, then takes the player code from mplayer to make videos play.

      From the mailing list:
      > > IMHO mplayer is good enough now that it won't lost in /dev/null if i leave.
      >
      > Pr
      • I think I see the Xine + Mplayer efforts with great regard. I think mplayer is indeed more for the techy oriented and far more chalenging from a developer perspective than Xine. Xine is cleaner and doesn't pretend to be the discoverer of the holy grail. Kudos to both of them. No matter which one I use I know I works because of al the unintentional but *combined* effort out in both Player (I'd include Ogle also)

  • Thanks Mplayer Crew (Score:2, Interesting)

    by ThoreauHD ( 213527 )
    I wanted to THANK YOU, and A'rpi of course, for what you've done. I would also like to thank the PLF at http://plf.zarb.org for making it useable on non-gcc 2.95 machines and for making the plugins so accessible.

    Mplayer is a kickass player compared to any OS/media player. Using linux would suck to no end without you.
  • Since this thread has set the tone, seems as good a place as any to ask, although it is offtopic:

    Is there a way to glue mplayer to mozilla so that I can watch streamed video? Realplayer, quicktime, and microsoft media all have some cracktastic protocol for streaming that seem to only work if you use the (slow) plugins, but once you suck down the file they play brilliantly...

    Is there a proper way to handle this ?

Slashdot Top Deals

Single tasking: Just Say No.

Close