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
@=
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.
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...
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.
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 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 !
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 ----
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.
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
Ahem... Make that meteorologist. I guess meterology would be akin to meter reading... :^)
Slashdot's first reaction to VMware
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
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.
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
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.
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.
You're making assumptions that simply aren't valid.
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.
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.
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
Remember, there are no stupid questions. But there are a lot of inquisitive idiots.
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.
If I develop any useful software, and I release it freely, that is damn well going in the license. :-)
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
"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.
--
xy=2
loop=0
This corresponds to the command line
mplayer -xy 2 -loop 0 <movie.ext>
I don't know how along ago loop was put in, at least a few months ago. xy has been there much longer. Granted, these are permanent settings, not ones that are saved when you toggle them in the GUI. And they were/are all documented in the manpage </cheapshot>.
The ocean parts and the meteors come down
Laid out in amber, baby.
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
The ends never justify the means.
I want to delete my account but Slashdot doesn't allow it.
That is why I
cast mplayer
Source based distros rock! I was never able to get mplayer to compile and work other distributions, primarily because the maintainers did not like the gcc that was running on pretty much any of them I could find. I am not sure what distro they use (perhaps lfs??) because they don't like Debian, they don't like Slackware, they sure as hell don't like RedHat/SUSE/Mandrake.. so who knows?
I should also qualify that by saying I haven't tried getting the result of my compile to work yet...
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.
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?
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
To be fair, I only ever tried to compile on Slackware, and there the configure script complained about the version of gcc (because the mplayer guys did not like any later gcc than the one before RedHat started releasing crazy gcc versions) and the compile did not work when the gcc checking was turned off. On the site, there were numerous nasty remarks about all the distros named (probably more) as well as against people daring to make packages of mplayer for said distros. At least the winex people tell you what distro they expect their stuff to work on, but I never saw anything but what distros mplayer would probably not work for (which was pretty comprehensably all major ones) and never got it to compile.