MPlayer 0.90 released; MPlayer Maintainer Leaves 338
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."
THANKS ARPI! (Score:4, Insightful)
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!
MPlayer rules... (Score:3, Insightful)
MPlayer is so cool.. they dont need to write their own GUI...
Re:Congrats to the MPlayer team! (Score:3, Insightful)
By using closed source binary codecs stolen from proprietary closed source programs?
Re:yes, exactly because of that (Score:4, Insightful)
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:Please (Score:3, Insightful)
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)
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
Idea for a new media player (Score:4, Insightful)
http://slashdot.org/comments.pl?sid=59962&thres
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)
developers attitude... (Score:4, Insightful)
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)
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.
Re:MPlayer rules... (Score:1, Insightful)
I do both, although like most code monkeys I have nearly zero talent on the UI side. However, I am personally getting increasingly tired of the attitude that "server side" and "backend" programming is the only path to real software.
Re:Gstreamer (and xine?) (Score:5, Insightful)
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.
Re:A'rpi ? (Score:5, Insightful)
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.
Is credit really given to the "true" authors? (Score:1, Insightful)
Am I the only one to think Arpi and the others from the mplayer team take way too much credit, at least for the coding part?
If you take a look at the mplayer source code, you'll see most of the code is taken from others' libraries: liba52, libaf, libao2, libavcodec,
Sure, they (the mplayer team) interfaced the whole thing together, but isn't that the easier part compared to codec development (at least I think)??
I think they did a great job to merge all together (I would have preferred a more modular/plugin approach) but I think we often forget the programmers of these wonderfull libraries. It's them you should thank for saying: "cool, I can play video x under Linux!"
ok, I stop whining..
Raph
Re:Good GUI? (Score:2, Insightful)
Re:Congrats to the MPlayer team! (Score:4, Insightful)
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.
So much hostility... (Score:4, Insightful)
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
Boo Fucking Hoo
Re:Good GUI? (Score:4, Insightful)
-adnans
Oh Please! (Score:4, Insightful)
"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.
Xine vs Mplayer (Score:4, Insightful)
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.
Re:Congrats to the MPlayer team! (Score:4, Insightful)
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:Attitude (Score:3, Insightful)
If you don't want to see that, use the -quiet or -really-quiet options. Most of that information is important for knowing how far into the video you are, or what went wrong. Yeah, a GUI will show that information, but with the current state, I don't think many use the GUI anyway. It doesn't seem to work on my system at all--the GUI is just shows a bunch of fuzz.
All of those are related. Mplayer is not clean and doesn't have a working GUI because they've been working on the actual video playing code. Xine isn't fast and doesn't support many formats because they've been working on the GUI and making the code clean.
Maybe, maybe not. I thought XMMS was going to be the default media player for Linux (and UNIX). I love it for listening to music, but video development has been ignored.
Do media players need to be encoders as well? I'm not so sure it is a good idea to go there. While a shared code base may be a good idea, I don't think merging a player and encoder into one program is beneficial. They have different goals. The player's goal is to decode the video and drop frames if it isn't fast enough. The encoder's goal depends on the source.
If the source is realtime (such as a camera, TV or VCR), then the overall goal is similar--do whatever it takes to keep the process moving--drop frames, use cheap algorithms to keep up, etc. The problem is I don't think it will benefit much from a shared code base with a player. Encoding and decoding are separate processes.
If it's from a video file, then you don't want any frames dropped, so you can't use the player's decoder because of what it does to keep up with real time. I tried to convert a video file using mplayer/mencoder, and that's the problem I had. It would skip frames to "keep up" so the output file was much more poor quality than if it would just take the time to decode/encode the file properly.
I don't share your confidence. Keeping the code and design clean takes time. Yes, it is good--especially for the long term, but it does not speed up development. Fast development will usually cause messy code and lots of hacks. This may be the reason mplayer is in its current state--in fact, if you look at the linked mails, A'rpi seems to say that.
Re:So much hostility... (Score:3, Insightful)
"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--it works for me. However, the developer is an obnoxious jerk who seems to spend more time belittling users than he actually would spend helping them.
Re:user's attitude... (Score:2, Insightful)
Read between the lines (Score:2, Insightful)
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, and it played files just fine. I had no problems whatsoever. These were the days when MPlayer wasn't even known, if it was known to anyone, they would say it was damn difficult or impossible to get it working. But that contradicted what I knew. After I read the DOCS, everything seemed easy and I understood how to do it. Then I realized, they already put forth everything you needed in the DOCS to get it working, even to a point a total newbie could understand. And I found myself agreeing with A'rpi, RTFM!! Why should they answer trivial questions when they had already answered it once?
So everytime I see someone that failed with MPlayer, I know they failed to read the DOCS even though they were told to.
Can't compile a kernel? Well a kernel compile is easier than it was compiling MPlayer, at the time (just do simple make commands). That is why he said that. If you can't understand how to compile something, then why are you downloading something and trying to do it yourself? It makes so much sense to me.
Re:will it lose the race against xine? (Score:3, Insightful)
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.
Re:Congrats to the MPlayer team! (Score:4, Insightful)
Re:So much hostility... (Score:2, Insightful)
Honestly, WTF is elitist about reading the docs???
Re:Oh Please! (Score:2, Insightful)
Just speaking for myself, I like the nice and simple GTK frontend that's included in the Mplayer source tarballs, but I love the fact that it's entirely optional even more.
And to all you Gstreamer fans, ever try to satisfy all of Gnome's dependencies if you're not running Redhat/Debian/Mandrake/etc binary packages? Try compiling Gnome yourself and then we'll talk about how allegedly "great" Gstreamer is. I swear to god, "Gnome documentation" is the biggest oxymoron on the planet. Ten thousand pages [gnome.org] all pointing to each other, none of which actually provides information on fixing problems.
Err, sorry. Didn't mean for this to turn into a rant, but oh well. Still mostly ontopic.