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...
mplayer is one of the best players Ive come across, but mplayer just 0wnz. And there was a time, where the only decent player (mpeg only) was mtv *ick*, how things change. take a look at freshmeat mplayer is teh best! ;) good luck to A'rpi.
http://www.fanboy.co.nz/adblock/
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
@=
Or would you prefer we were all MSN Subscribers rather than Internet Citizens?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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've used Avifile in the past and it worked well.
Ha! Take that Slashdot!
I'm currently making some Slackware 9 packages for it. I'm trying to get it to compile with the Quicktime codecs, but it seems kinda broken (I probably screwed up somewhere)
The new default skin is really cool looking...
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
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
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?
Why not join forces with the gstreamer team? I think gstreamer is the way to go for the multimedia in linux, that one is really a multimedia framework, not that i don't like mplayer as a stand alone player .. but it's not that scalable as gstreamer
I fuse with Mercer every single day...
Insightful my eye. Mplayer can already be ran from the command line (man mplayer), and there are front ends for Mplayer (KMplayer for example).
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.
Why do you set your hopes on gstreamer? On my Celeron 333 I cannot even play a simple mp3 file with the gstreamer player, while MPlayer is working fine. Also, gstreamer is broken with i686 optimized glibc.
It would still be cool to have the backend core code cleanly seperated out, with well defined plugins for codecs. In other words, MPlayer could be the media framework to end all media frameworks.
Now that would rock.
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
I've been using this player religously ever since ,
,
:D
I moved to linux , and now that they've chosen
a default skin , I hope they incorporate it into
the project properly (ie default download
compile includes it)
I love showing my 'doze friends look I'm playing
an avi , followed by a dvd , vcd , mov , rm
etc... all from the same program !!! They just
look flabbergasted and upset.
Then I go look I'm re-encoding using the same
program (well source base at least) and once
again they're flabbergasted , and wow hey no voice
sync problems either
This is definatly one of the programs that makes
my life a lot easier using linux
It would be a shame to see mplayer lose maintenance, but I'm sure someone will step up to the plate. Xine never could cut it quite like MPlayer as far as stability, customizability and the number of file formats supported.
Why if it wasn't for mplayer i wouldn't be able to play divx files on my powerbook without trying to configure the heck out of QuickTime (which i never managed to get DivX working in).
- tristan
Check out how the FreeBSD ports tree does it for clues on how to compile it. All you have to do is 'cd /usr/ports/multimedia/mplayer; make install' and it'll work. Perhaps you can figure out how things work from inspecting the Makefiles.
You can find the information here.
Does anybody have the changelog between rc5 and the final version? I can't seem to find it anywhere on their website.
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 !
check the hungarians out =)
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..
---- Booth was a patriot ----
I suppose this is more stable than the previously stable version was before the previous stable verison before the......original stable version . I feel a bit wonky now ... having said that.
There are already a few decent attempts, the one I like the most is KPlayer.
I just have to say it: THANKS MPLAYER PEOPLE. I have no idea who you are etc. but I am very, very grateful for the work you have done. mplayer is my mediaplayer of choice on linux. It simply rocks. I've tried xine and aviplay but I've always returned to mplayer. It's simply the best there is right now.
So, thank you.
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
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.
Is it 'Release Early, Release Often?'
> 459 days after the previous stable release
Indeed, Good Work Gentlemen!
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.
I like the VideoLAN client more than any other DivX players for Mac OS X.
Mplayer is nice too, I use it to view subtitles on my movies.
http://twitter.com/gr
Quick! Somebody do the queen to make up for the $-grubbing ... grub.
The maintainer for the awesome Meterologist weather program for OS X has decided to stop maintaining the program for at least the next few months... There doesn't appear to be a "second in command", so it looks like this program is going to languish. The source is open. Any takers (I would, but I'm about to enter grad school)?
Slashdot's first reaction to VMware
Thanks for playing, you loose. From the MPlayer Changelog:
...
.asf file format detection added (no .asf reading yet!!!)"
29.01.2001, mplayer v0.11-pre11
"streaming fixes, asf support pre, indeo5 fix
From the avifile "Old News" page
22.01.2001, avifile 0.6
"completely rewritten AVI and ASF code"
Note that that is rewritten ASF support, a week before the initial support for ASF went into MPlayer CVS. The earliest mention I can find on the avifile page is this:
23.12.2000, avifile 0.53
"Added decoding-only support of Windows Media 7 video format ( fourcc WMV1 ). This format is frequently found in ASF files in the 'Net."
Which is about right, as I was using 0.5x and 0.6 to watch a few DivX;-)'s back then, and remember fooling with some ASFs because I could.
Avifile had working ASF support at least two months before MPlayer even had preliminary ASF support.
Now give it up, please.
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
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
You know how people tell newbies to RTFM, use mandrake/redhat? RTFD -Documentation.
If you can't build mplayer from source (I did) then you're suffering from a bad case of "AALAYT" (Ain't As Leet As You Think)
Solution #1: read, follow directions,
Solution #2: install redhat/mandrake, install apt-get and use BINARIES. (freshrpms, texstar)
apt-get -y install mplayer-093
--Who said compiling software should be easy?
With the recent developments in libavcodec MPlayer no longer needs Win32 codecs that badly. I can play all my WMV files without problems enjoying 35% less CPU load. For QT and Real you still have to go with closed source DLLs, though.
...I use mplayer in Windows now. It's much better than any of the crappy win32 codecs. Hell, the Win32 DivX codec can't even play partially downloaded files.
MPlayer runs fine and dandy under Cygwin and since last week it also runs under MinGW, so you might say that we have a true Windows port now.
mplayer (0.90)
final: "CounterCounter"
DOCS:
* Chinese man page added
* Chinese, Hungarian, Italian, German and French translations updated
* libavc-options.txt and vop.txt merged into the man page
* XviD instructions updated, AAC instructions added
* numerous help file updates
I don't think I have ever used a 'stable' version... whatever is in CVS is fine for me. There's no long waits for new versions that way. I some how doubt that a 'stable' release will crash any less than what I've seen in CVS. Most projects don't seem to do any kind of rigorous bug checking/fixing before release.
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...
One of the more overlooked features of MPlayer is the EDL (edit decision list) system. This allows for real-time editing of video streams during playback. This kind of functionality pushes MPlayer/mencoder one step closer to suitability as a backend to a non-linear digital video editing system.
You can use EDL for all kinds of things. One that comes to mind it to dynamically skip over commercials or advertisements in video streams. Another may be to skip over or mute content that you may find inappropriate or offensive; this occurs during playback, or the original video stream is left untouched. This works with any kind of media that MPlayer is capable of decoding, which makes it a very useful feature for many potential uses.
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.
this app kicks! i love it!
thanks for the great work guys! and here's to version 1.0!!!!!!!!!
cheers,
jonah
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.
Actually I'd argue that your attitude is "utterly ridiculous." Seriously, they're providing a product _FOR FREE_ they have little or no reason to bend to your whims. You can make suggestions, and perhaps they'll follow them, especially if you ask nicely or thank them for such a well written app.
Think about it. If you'd put alot of time into some project and provided it for free would you be willing to both put up with answering question XYZ for the 10000th time, especially if it really is covered in the docs? Would you be willing to put up with people that demand you fix something?
Think about it.
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.
Let's not forget his contribution, and what a contribution it is. If I had made multimedia available for free, being a former coder myself, I'd
1. have an attitude
2. practice a swagger
3. "I'm going to walk the earth"
"What do you mean, walk the earth?"
"Like Kwai Chang Caine in Kung Fu"
4. Make some money with coding skillz (aka Profit!)
This was the way i understood it as well. But even if you dont use the proprierty DLLs you can play most of the common movie files, including wmf if I remember it right (Didnt look into the file though, maybe it was just a file with a wmf-extension). If they would include the player without any closed libs or potential copyright conflicting source they could add a huge benefit to their distributions. Especially if they would include plugins such as plugger.
When I saw MPlayer, I, as well as many others I'm sure, thought of the shitty game service at www.mplayer.com ..
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 ?
25% Funny, 25% Insightful, 25% Informative, 25% Troll
gui is still disabled by default. Why?
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.
Malike Bamiyi wanted my assistance.
'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.
"too many perfectly good frameworks already"? Can you name me some on Linux? And keep in mind that we're just talking about MULTIMEDIA?
Speaking as a video tinkerer and 3D animator, I see a good "multimedia framework" to be the same thing as programming using the GNU tools. The tools(yacc, gcc, flex, bison) need not have complicated and explicit linkages to each other; each one just does one simple thing, and passes it on the the next. The framework just defines a standard way for the tools to talk, and keeps the chain going(make, or the shell). make calls yacc to prepare input, calls gcc to create the binary, and then calls rm to clean up after itself. Make doesn't know, or NEED to know anything about these tools in advance. And anything that's aware of the framework now gets all of those capabilities for free--you can call make from a perl script, or chain together the tools in an order that the original developers never thought of. That's the kind of power we're talking about.
Your strawman argument of "every conceivable thing" makes no sense. It's not(and shouldn't be) the job of the framework developers to make it do everything--it's their job to make sure that the module that can do that "conceivable thing" can talk to the rest of the modules in the framework, and that the framework can be extended at the user's discretion.
Granted, I'm not trumpeting gstreamer as a paragon of exemplary code. It sounds like it's still very much in the development stage--but I see nothing wrong with that.
- Planning
is where the difficulties should be arising from--bad code can always be optimized, but a bad design is forever.Instead of seeing Yet Another video player in gstreamer, you should really be seeing another Mozilla. It's big. It's complicated. It's hard work. People ask what the point of it is. It will be awhile before any good results come out of it. But when(if) it bears fruit, you may well find yourself asking how you did without it.
--
Anyone have suggestions for me?
:(
I tried with mplayer from 0.89 to 0.90rc3, and dvd has never worked fine for me!
I am using savage video card.
p3 1ghz
256mb ram
savage card supports xv, mtrr is enabled
yet..
in windows powerdvd plays dvd's flawlessly, perfect syncing etc, mplayer, no matter what I try, will only play it synced for 30 seconds in windowed, forget fullscreen.
Then, when using the gui, after i move the mouse, i get a black square where the curser was.
go windows for multimedia, maybe when linux matures in desktop systems will i consider it again.
I actually use mplayer as my music player of choice now. I like the keyboard control, the doesn't-need-X-ness, the choice of output method (I use esd for local streaming - I know it sucks, but it works) and the support for many codecs... :-)
Oh, and I like the developers' style...
Paranoia isn't an infectious condition, it's a way of life
While mplayer can really play absolutely ANY file, it has a big downside that most people don't seem to see (and help there).
:-)
First (as someone other pointed out), the code is a real mess.
I've been there, I've hacked around, I've made the DVD-key-caching possible (and I was the first one to have that idea, it seems).
I tried to fix problems with fullscreen (if you press 'f' only the current file will be fullscreen, the next ones not) and (e.g.) video-out initialized for every file which leads on my 1800x1350 virtual desktop to the window appearing somewhere as it's destroyed and created for every file you play (this only in my private hacks) and I didn't succeed.
Second there are too many static options in mplayer, eg you can't change the postprocessing "on-the-fly", my dvd-seeking puts you somewhere random (try to seek to the very second you see on the OSD with commandline-switch -ss).
All the guys contributing made an incredible job and I enjoy every release. But I am allowed to criticize because I hacked around and you not I think
The ends never justify the means.
I want to delete my account but Slashdot doesn't allow it.
I'm going to take offence at the "here's hoping some improvements come of this" comment. What sort of improvements would you want as a result of one of the main developers leaving? Improvements? Where was mplayer one year ago? Where was dvd/ divx/ windowsmedia/ quicktime/ vivo/ other-formats-obscure-and-not playback under linux a year ago? I feel it is almost like saying 'oh, are biggest contributor has left the organization, lets hope some improvements come of this' as if they were not helping at all or were detrimental. The whole of mplayer would be quite different without A'rpi.
fair.org counterpunch.com truthout.com indymedia.org salon.com
eff.org guerrilla.net debian.org gentoo.org
Don't worry, a Redhat 10.0 will be out in a couple of weeks, claiming "vastly improved media handling", and that they had to rollback those kernel improvements again.
All the mods with an IQ of less then 10 fell for it.
Asking someone to read a manual or faq before they ask anything is elitist?
What about the aditude of some of the users? Like for example the users who want everything handed to them on a sliver plate, will not be helpful by reading the faqs/manuals, bug the devlopers with their related as well as unrelated demands and questions, etc.
I really think the people here who are complaining about doing something as simple as RTFM/RTFA, and saying that the runners should be more friendly should try doing a project like this.
See how long it takes them to go from answering each and every repeated question, being nice to those who ignore you and ask the same thing for the Xth time, doing the same for the yellers and complainers, trying to get some programming done between doing tech support for 100s of users, etc to telling them "RTFM/RTFA!"
Anyone figure out a command line for mencoder to record from a v4l device directly to an MPEG1 or MPEG2 file with the appropriate limitations for VCD or SVCD (respectively)?
2 40:fps=29.97:adevice=/dev/dsp:amode=1:volume=51000 -ovc lavc -lavcopts vcodec=mpeg1video:vbitrate=1152:vhq -ofps 29.97 -oac mp3lame -lameopts cbr:mode=0:br=224 -o myvideo.avi
2 40:fps=29.97:adevice=/dev/dsp:amode=1:volume=51000 -ovc lavc -lavcopts vcodec=mpeg1video:vbitrate=1152:vhq -of mpeg -ofps 29.97 -oac mp3lame -lameopts cbr:mode=0:br=224 -o myvideo.mpg ...but this file ends up with no audio, even though mencoder claims it's encoding audio into the file.
The closest I've gotten (for VCD) so far is:
mencoder -tv on:driver=v4l:norm=ntsc:input=0:width=352:height=
Unfortunately, this produces an avi file, with an mpeg1 layer 3 audio stream... as I understand it, a layer 2 stream is needed (not positive about that).
Also, what's needed is an mpeg file format, not mpeg1 data in an avi wrapper.
The following produces an mpeg file...
mencoder -tv on:driver=v4l:norm=ntsc:input=0:width=352:height=
Anyone know how to produce a VCD-ready (or SVCD-ready) without having to record in one format and convert/re-encode to another format before burning?
- Preferences: Solaris 10 (servers), Ubuntu (desktops), Solaris 11 (personal servers) -
I still remember the first time I installed mplayer. Read thriugh the FAQ I came across an entry of the form:
.....?
How do I
You don't know how to install a libary? What are you doing on Linux? Run ldconfig....
What an ass! Maybe he was born knowing that but I certainly wasn't.
His lousy attitude actually manaaged to get mplayer called "The project from hell". onlinuxworld.com.
Maybe now the project will become more friendly and quit scaring users and developers away.
Life is too short to proofread.
Slashdot IS a good source for news, if not the best.
Both players are good, it just depends on your philosophy. I think that xine's gui wastes screen space, and xine eats processor time. Plus, it locks up unresponsively. *shrug*
But the point is, there are now two independant, very good movie players for linux. and that's cool.
And using the plf's xine libs, you are all set for dvd playback. mplayer builds usually have them in the code.
I'm happy.
Who is this Anonymous Coward character, how does he post so much, and why is he always such a whore?
Come on...i would never...would I?
" Looks like you're too late. Welcome to the consequences of these attitudes most Linux developers seem to possess. Disillusioned users."
To be "disillusioned", there first has to be an illusion. An illusion born out of desperation. Desperation to escape the monster that Windows users created...Microsoft. They wanted "ease of use"? They got it Microsoft style. They wanted a big brother to tell them that everything's safe, and that those scary computers wouldn't hurt them. They got Microsoft to wipe their bums, and blow their noses. Now the Microsft monster that user apathy, and fear built is showing it's true colors and Windows users are seeking any lifering they can. Some are fleeing to Apple, but Apple scares those who's only world view has been Microsoft and Intel. "Think different", indeed. Linux appears to be a strong contender, and the word "free" tempts as well. Flee the horde swells bringing all their prejudices, and whoa any developer who dares differ, for the developer and his movement were "Think different" before different was even cool. Now developers all over the world do battle with the "Peter Pans" that Microsoft spawned. For they do not wish to read the books that the adults read, and speak the adult words, for that is to leave the safety behind, and take a bold step into a world were, thinking for oneself is both scary and rewarding. And be such a world not perfect, but a challenge to further step into adulthood and meet it head on with it's RTFMs and it's attitiudes for the reward is far greater than going back.
"Docs can often be confusing. Sometimes ou can't find your answer in the 100's of pages of documentation that comes with a lot of software. Sometimes you misinterprite things. Sometimes you don't know where the fuck the documentation is. And sometimes you plain just don't get it. When that occurs, it helps to have the problem explained in slightly different language. To blindly respond with "RTFM' does nothing to help your software community. Most sensible advice does not come with expletives attached. You might not care, but that's no reason to act like an ass."
OK now that it has been covered what the developer should do. How about printing out for the rest of us what the user should do, and maybe, just maybe you'll see how things like this come about.
are you actually asking devs to sync their release dates with the distro (package) makers?
sounds a bit M$ to me...
Get off the podium. You're being drowned out by our Windows Media 9 movie projection.
"Sufferin' succotash."
Note the similarity with Mozillas recent admission that it's becoming difficult to maintain a coherent, focussed development path - coders move on, people get day jobs. Now the Mozilla people are focussing on ensuring proper peer review strcutures are in place for code review. As they say, nothing in life is free. Will these pressures force more open source projects to be reevaluated?
I've been using mplayer for a long time now, and I am compelled to say: I haven't seen a media player that is nearly as useful as mplayer is, no matter what the platform. Mplayer is a killer app, and is a big motive for me to use Linux over other choices.
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.
1. EULAs are to be ignored. Unless both parties sign a contract you can ignore the EULA and simply obey the copyright laws in your locality. Except for two states in the US.
2. Software patents are only a problem in the US. Notice the point of origin for mplayer.
Democrat delenda est
You have no idea what you are talking about.The story goes like this:
1) Arpi gives a fuck about GUI, so there is none
2) Arpi gets paid to make a GUI, so there is one
3) Because Arpi is a good (but messy) hacker, the GUI is great, in GTK, integrates just fine with KDE and every desktop/windowmanager that uses the common hints.
4) Just last week there was even a theme contest. The GUI is alive and works/looks/integrates wonderfull.
Why is it disabled by default?