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."
Wha? (Score:4, Funny)
Re:Wha? (Score:2)
Gues that means Duke Nukem Forever is out tomorrow.
fp? (Score:2, Offtopic)
okok... (Score:2, Interesting)
cu,
Lispy
Re:okok... (Score:3, Interesting)
Congrats to the MPlayer team! (Score:5, Interesting)
Re:Congrats to the MPlayer team! (Score:3, Insightful)
By using closed source binary codecs stolen from proprietary closed source programs?
yes, exactly because of that (Score:2)
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:yes, exactly because of that (Score:4, Informative)
Re:yes, exactly because of that (Score:2)
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, and will be unable to complain. The world is not unfair, actions have consequences.
For example having used Win95 because it was bundled, and then Office because you could use your friends illegal copy has brought me a lot of trouble.
Re:Congrats to the MPlayer team! (Score:5, Informative)
Re:Congrats to the MPlayer team! (Score:3, Interesting)
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. And it's nice that I have a means of listening to those NPR audio streams too. I wish you the best of luck.
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
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.
Re:Congrats to the MPlayer team! (Score:3, Funny)
it's ok to cuddle up to naked chicks, as long as the software from the EvilOne(tm) looks ok on the screen, ideals be damned
But thats just me..
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:Congrats to the MPlayer team! (Score:4, Interesting)
mplayer? Plays everything? You obviously don't use powerpc-*-linux or alpha-*-linux
Re:Congrats to the MPlayer team! (Score:2)
I've seen it in action. It's flawless.
Imagine real time scrubbing through video. Loading up divx/dvd/mpg in under a second. Flawless sync. And more.
Re:Congrats to the MPlayer team! (Score:4, Insightful)
Re:Congrats to the MPlayer team! (Score:2)
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 make it a bit easier by including a big bundle of codecs though.
If you really hate the fact that it's closed source, why don't you join the FFMPEG team (which mplayer uses the codecs from) and start hacking? I'll enjoy my non-pirated[1] movies of nearly any format in the meantime.
[1] I know enough about troll logic to know what's coming next.
Re:Congrats to the MPlayer team! (Score:2)
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 instance: mp3 has no value, the more value fraunhoffer(sp?) asserts, the more appealing Ogg/Vorbis becomes...
Re:Congrats to the MPlayer team! (Score:2, Interesting)
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...
Re:Congrats to the MPlayer team! (Score:2)
mplayer crashes for me constantly.
xine never does, and I'm running beta versions.
mplayer has no dvd menu support.
xine does.
mplayer craps out on fullscreen with xinerama.
xine gives you the option of crapping out like mplayer (spreading across both displays) but defaults to normal behavior (fullscreen on one display)
xine is easy to use
mplayer is not
half the time mplayer won't play sound, especially with QT
xine always does
anyway this is all just my own personal experience. I keep mplayer around, I'm now upgrading from rc5 to
oh and about playing a dvd being ui voodoo....whatever that means....
1. put in dvd
2. click DVD button
3. click Play button
doesn't seem too hard to me.
last time I tried to play a dvd with xine....it was an rcX...I seem to recall something about -dvd and maybe having to specify the chapter, or something? I don't recall if it even read encrypted dvds....anyway movie playing is decidedly a "Desktop Machine" function. all my file management is done in a console, most of my time is spent there in fact....but I don't want friggin command lines on my movie player. apps like that are supposed to be straight forward and easy to use: here's a movie, play it. screw mounting a dvd, finding which vobs are the biggest, and specifying the title on the commandline. (and it's the same with vcds....and of course a click of the VCD button in xine).
so anyway if you haven't tried xine in a while, give the newest beta a try. there's some bugs, but really, it's a stellar application. if you're happy with mplayer, fine. I think it's silly for there to now be a holy war over movie players. I haven't had good experiences with mplayer, but there's plenty of people who have. anyway....I encourage anybody to give them both a try, and now it's time to stop wasting time on slashdot
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!
Re:THANKS ARPI! (Score:5, Informative)
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)
mencoder -o output.avi -oac copy -ovc copy filethatsyncsbad.ext
It even makes files that play correctly play more smoothly.
Re:sync issues (Score:2)
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 months since I checked it, but I can reproduce the problem...
Re:THANKS ARPI! (Score:2)
I thought transcode used mplayer's shared post proc library too. Did they finally implement this on their own?
Re:THANKS ARPI! (Score:2)
Wasn't that actually the libavifile [sourceforge.net] guys...
Re:THANKS ARPI! (Score:2)
MPlayer rules... (Score:3, Insightful)
MPlayer is so cool.. they dont need to write their own GUI...
well (Score:4, Informative)
Sound so familar (Score:3, Interesting)
wait a minute, why this sound so familiar?.....
Oh! Micro*shot*
Windows port? (Score:2, Interesting)
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.
Re:Windows port? (Score:3, Informative)
According to the FAQ [mplayerhq.hu] you can compile it on Windows using Cygwin [cygwin.com]. On the subject of ports, Mac OS X users may be interested in MPlayer OS X [sourceforge.net].
Re:Windows port? (Score:5, Informative)
Free of course. Sister project is free videostreaming!
Re:Windows port? (Score:2)
Re:Windows port? (Score:2)
Re:Windows port? (Score:2, Informative)
Both player are able to handle all DirectShow codecs (incl DivX) as well as RealMedia, QuickTime, and also DVDs.
jetAudio installs the RealMedia codecs, but no QuickTime codecs. Media Player Classic installs no codecs at all (that's why it's so small).
Embedded Mplayer (Score:5, Informative)
Big thanks to the developers., for this one.
Re:Embedded Mplayer (Score:4, Informative)
It's just started, but already usable and quite nice. Very promissing.
Re:Embedded Mplayer (Score:5, Informative)
will it lose the race against xine? (Score:5, Informative)
Re:will it lose the race against xine? (Score:2)
Re:will it lose the race against xine? (Score:4, Informative)
Re:will it lose the race against xine? (Score:2, Interesting)
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 open source model.
If you are making the second kind of software you need to make a gui. You need to make an easy installer. You need to think about all the things a closed source company thinks about. The way I see it there are very few of the second type that have succeeded. gaim, Mozilla, CDex, DC++. That's about it. Every other piece of OSS has failed miserably in some way.
mplayer is one of those that has failed. I know how amazing it plays video. But the effort of making it work is greater than the benefit of using it. It should come in a single executable file that installs it. It should then have a GUI that works no matter what and never crashes. And it should play everything out of the box. It doesn't, so it is the loser.
On the subject of GUI (Score:3, Interesting)
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.
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:will it lose the race against xine? (Score:3, Informative)
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). Funny, but nobody else had such unusual compiler requirements.
-licensing problems(some of the rants are truly spectacular.) At one point he went and dug up other projects that he felt were worse violators, as if to try and shift people's attention/justify his own problem. It was pathetic.
-Distros "incorrectly building" the player(I think it was how they were linking to libraries), which would then send floods of users to them(and, of course, they think all their users are idiots). Mplayer is by far the most anal-retentive about distribution of binaries, and as a result, the distros have told them to kiss off distro-style(ie, mplayer's been dropped from the major distros)
Mplayer got a bad review for (surprise!) having "developers [who] were unfriendly and ... documentation incomplete and insulting." His response? He attacks the author of the review with several bullet-points in the DOCS TO MPLAYER ITSELF! As someone once told me, "it's better to keep your mouth shut and let people wonder if you're an a jerk, than to open it and remove all doubt."
In each case, it was "mplayer versus the world", and in his opinion, the world could go screw itself. The docs, the website, even the messages in the configure script and the program itself- were all confrontational, and/or insulting; sorry, I don't like software that cops an attitude. This guy, if not the entire team, had serious problems with keeping their mouths in check. So, when I hear he's leaving, I can only say GOOD.
As I download this latest release, I can't help but remember how nothing changed with each release candidate up to this; the volume control doesn't work, the OSD is broken, some files give it complete conniptions but play fine in Xine, and it takes an enormous amount of CPU power now. Used to take about 2-5% of my CPU, now it takes 50%. Playback is jerky, too. Xine? None of these problems(sync is often better, playback is smooth, CPU usage is minimal/non-existent.)
Maybe the reason he's pissed off is because Xine is using his code(as they can- if you didn't like the concept of others using your code, you shouldn't have made the project open-source), but using it -BETTER-.
Re:MPlayer is working fine, gstreamer not. (Score:2)
But GStreamer's code architecture is a lot more modular than MPlayer. That's why I hope GStreamer will win in the long term; in the short term, MPlayer is fine.
Re:MPlayer is working fine, gstreamer not. (Score:2)
I'm pretty sure that hasn't been true for a while - the opt scheduler took care of that stuff.
Hope this project doesn't fall by the way side (Score:3, Funny)
Re:Hope this project doesn't fall by the way side (Score:2)
This close race is a Good Thing? in my book. Since the end user doesn't have to make a choice, but can keep any number of media players installed, the end user always wins :)
Re:Hope this project doesn't fall by the way side (Score:2)
Yeah, I always found that xine crashed when it got to the scene with the marmalade and the parrot...
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)
Re:Idea for a new media player (Score:4, Informative)
Re:Idea for a new media player (Score:3, Informative)
Then we would be pretty much dependent on the speed of the CPU rather than any nice tricks that the different systems are capable of. Examples:
Apple makes uses of Altivec instructions in the G4 to get improved performance on the sort of ops that these plugins do.
SGI IRIX based systems make heavy use of the graphics subsystem (which is why they still command big bucks) for this sort of operation.
What you suggest wouldn't gain much approval from users as it wouldn't allow them to use the full power of the machines. Imagine having a system with a new graphics card and getting poor frame rates because the plugin didn't take advantage of the features of the card.
Re:Idea for a new media player (Score:2, Interesting)
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 the highest possible quality. Most of the rest is just preference, and you don't even want to generalize that.
Developers are very keen on the cost of even the slightest code duplication, but they rarely consider the cost to the user of having to hunt for and install the latest libraries, the small bugs that are caused by slightly different versions of libraries, and the tripling or even quadrupling of development time that it takes to produce solid resuable code.
MPlayer rocks! (Score:2, Informative)
Gstreamer (and xine?) (Score:2, Interesting)
This is one important step getting linux closer to the desktop.
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.
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.
Maybe we'll finally get some threading (Score:5, Interesting)
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.
Re:Maybe we'll finally get some threading (Score:2)
Re:Maybe we'll finally get some threading (Score:2, Informative)
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)
You mean THAT A'rpi ?
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.
Mod parent up (Score:2)
Re:A'rpi ? (Score:2)
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 Real OS with a (mas o menos) n00b friendly interface. But hardware that's built like a Mercedes costs Mercedes prices. Most people are tooling around in Intel Toyotas and Athlon Nissans...some even are in VIA Kias.
We need to spend a little time studying how the Mac community treats newbies. Visit your local Mac User Group sometime. There are no snarls of "RTFM" there. You would find it instructive.
Re:A'rpi ? (Score:2)
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.
Oh come on... (Score:4, Informative)
Re:developers attitude... (Score:2)
And need I remind you and any other anti-social developer out there that the purpose of the mailing lists like these is to make suggestions, report problems and otherwise provide feedback regarding the progress of the project. It's not meant as an ego-feeder or a means to degrade others with insults... though sometimes it just seems like that.
Re:user's attitude... (Score:2)
I was very nice and polite. I did read the documentation and there was nothing regarding the suggestion(s) I made. To be more specific, I requested that the GUI settings be remembered or retained in some way so that I didn't have to make the display "double-sized" each time I ran a video clip. They suggested a modification to the command line. I tried it and it didn't work. Maybe they planend to make it work, but it didn't... the option wasn't even recognized.
Next I suggested they create a "loop" feature so that videos can be played as a loop. They said the idea was stupid and didn't even offer a CLI option in that case.
The fact that it's free has no bearing over this matter. There are many free projects that do not suffer from this problem. Accepting abuse is not part of the GPL.... at least I didn't see that in the fine print anywhere.
Re:user's attitude... (Score:2, Insightful)
The timing of the release could have been better.. (Score:3, Interesting)
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)
Never used it, but udos to him anyway (Score:2)
Even if they cant do it forvever..
non-DVD subtitles? (Score:2)
Ok, I have RTFM and know this is not the best place in the world to ask for it. But hey, I'm desperate
Re:non-DVD subtitles? (Score:2, Informative)
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)
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: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.
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.
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:Xine vs Mplayer (Score:2)
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
>
> 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...
Re:Xine vs Mplayer (Score:2)
Thanks Mplayer Crew (Score:2, Interesting)
Mplayer is a kickass player compared to any OS/media player. Using linux would suck to no end without you.
Mildly OT: Streaming video ? (Score:2)
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 ?
Re:Attitude (Score:5, Interesting)
I hope the first thing they do is clean up the code. MPlayer lost _many_ developers to xine lately. xine has not caught up to MPlayer in speed and number of supported formats. Also it seems to be still less stable and more vulnerable to broken video files, but the code base is MUCH more clean (xine sources can actually be called beautifull) Maybe this disruption of MPlayer development can also be seen as a chance for a more unified default mediaplayer for linux, i.e. xine.
The one thin xine is lacking is an encoder a la mencoder. But there is some development with enix. The design looks as clean and easy as xine and I am pretty confident that enix can catch up to mencoder in a short time provided that some more developers are interested.
Cheers
Re:Attitude (Score:2)
Hrm, be careful what you wish for. Xine may be nicer than MPlayer codewise but IMO GStreamer is nicer than Xine, as well as being powerful, with lots of promise.
There are still some things that need to be done with GStreamer before you could say recreate Xine - it needs interactivity support for DVDs etc.
Long term though it's pretty obvious that Xine and GStreamer are going to compete for the multimedia framework - I have no idea if that's bad or good.
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:Attitude (Score:2)
Because that's not their job. Their job is to play movies. Do you complain that Apache doesn't have a gui? No, because if you really need a gui, you use a frontend.
MPlayer is supposed to be flexible and robust. You have a choice here really:
1: Have the MPlayer team make their own gui, which uses one toolkit, so it only integrates (if at all) with only one desktop framework (kde, gnome, mozilla, gnustep, whatever).
2: Have the Mplayer team waste their time by writing a seperate qt/kde gui, a gtk1/gnome1 one, a gtk2/gnome2 one, a plain gtk one etc etc etc... and be complained to by all the ui experts that it doesnt quite comply with their styleguides.
3: Have no gui, let other people sort that out for themselves. Concentrate on doing your job well. If someone wants to write a nice kpart wrapper, they can do it (and they'll probably be better at it than the mplayer team trying to spread their time thinly). If someone wants to use in its barest form for an embedded device, a pvr or something, they can do that and have no troubles.
What the team seem to have done, is they started with no gui, went with option 1, and then sort of realised that its not a fantastic idea, and seem to be abandoning it.
Re:I just completed downloading it! (Score:3, Informative)
should suffice for a Slackware 9 system (It's what I use). Be sure to put your codecs in
Re:Good GUI? (Score:4, Funny)
Re:Good GUI? (Score:2, Insightful)
Re:Good GUI? (Score:4, Insightful)
-adnans
Re:mencoder directly to VCD/MPEG1 or SVCD/MPEG2? (Score:3, Informative)
Something like this should work (for VCD):
mkfifo stream.yuv
mkfifo audio.wav
mplayer <tv options here> -vo yuv4mpeg -ao pcm -aofile audio.wav <
cat stream.yuv | yuvdenoise | mpeg2enc -F 4 -f 1 -n n -a 2 -o video.m1v &
toolame -b 224 -m s audio.wav video.mp2
mplex -o video.mpg video.m1v video.mp2
'course, this is all assuming your box can handle decoding the TV stream and encoding the video and audio simultaneously.