Slashdot Mirror
MPlayer 0.90 released; MPlayer Maintainer Leaves
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."
I'm in shock! No Mplayer-pre576 !
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
MPlayer is very promising though controverse project. Lets see what it all boils down too after the reconstruction...I use it and like it.
.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, 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.
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!
...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 Arpi is still there on the mailinglist doing stuff, he's just not the maintainer any longer.
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*
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.
Ander
@=
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.
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?
The owls are not what they seem
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.
Yes. And we love it!
Seriously, ofcourse it had been better to do it in some other way, but what do you propose?
This is by far the best Linux Media Player out. Plays all my pr0n :)
Strangely enough, each thread I comment on, seems to lead into a discussion relevant to a story not-yet-posted.
h ol d=3&commentsort=0&tid=188&mode=nested&cid=5684 779
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)
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
"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.
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...
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.
still reading?
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.
---
the pen is mightier then the sword. the sword is mightier then the court. the court is mightier then the pen.
"How do I..." "RTFM IDIOT!!!11"
You mean THAT A'rpi ?
...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.
And I really hope they loose theit fear of Version number 1.0. I am pretty amnazed that Arpi leaves without having a half decent 1.0 out. gui is still disabled by default. Why? Largefiles: disabled. Why? The output mplayer sends to stdout is still a incredible mess. I wonder why he leaves the project without cleaning up these few last bits. In principle MPlayer is the most usable, stable, and featurefull media player for linux. Only thing is, it's a mess.
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
KdenLive/PIAVE - non-linear video editing
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)
A slashdotting - you get the stick first and then the carrot !
You don't need to add any special compile-time flags for Quicktime anymore. That changed about 3 or 4 releases ago. ./configure --enable-gui --prefix=/*temp dir*/usr/
/usr/lib/win32 before compiling, and then copy them to your tarball directory before running "makepkg". Be sure to keep the same directory structure. Run "makepkg" in that temp directory.
should suffice for a Slackware 9 system (It's what I use). Be sure to put your codecs in
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
Why would anyone want a GUI in a movie player? Movie theaters and TVs don't have GUIs, they just show it all in fullscreen, just they way I want it. A GUI would only be a distraction and a waste of screen real estate.
Escher was the first MC and Giger invented the HR department.
looks like i was waay too nervous while trying to make a firstpost. Of course youre right, Mplayer rocks, and it resides on my Mediahub at home. Maybe someone could explain to me why it isnt included in most distributions yet? I once read about licensing issues but still dont fully understand.
cu,
Lispy
"The best laid plans of mice and men gang oft agley..." - ROBERT BURNS
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.
... 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!"
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
IMHO, the real strength of MPLayer is that it doesn't need ANY GUI! Just fire it up in fullscreen and enjoy the Movie.
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
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...
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.
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.
Carpe Daemon
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.
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.
Remember, there are no stupid questions. But there are a lot of inquisitive idiots.
'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, 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.
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.
I would just use mplayer with the yuv4mpeg video output driver, and the PCM audio output driver. Create two fifos, one for the video called stream.yuv and one for the audio, say audio.wav, and tell mplayer to write the video and audio to the fifos. Then, using mjpegtools, encode the video from the yuv4mpeg stream, and use toolame for the audio. Then, mplex the resulting streams together, and voila, you have a VCD or SVCD.
/dev/null &
:) OTOH, if you're running an SMP box, this technique is probably more efficient...
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.