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."

Comments

R0FST ST0P

[Anonymous Coward]

Feeeeckers!

Wha?

[evilviper]

I'm in shock! No Mplayer-pre576 !

Re:Wha?

[The J Kid]

You're right.

Gues that means Duke Nukem Forever is out tomorrow.

Re:Wha?

[Anonymous Coward]

This release is said to be a stable release, but in fact I've never found that any release of mplayer was unstable or unusable.

Re:Wha?

[Afrosheen]

And right after that you can download and install E17.

Re:Wha?

[evilviper]

Yup, and Linux will be ready for Joe Six-Pack's desktop.

fp?

[Lispy]

MPlayer is very promising though controverse project. Lets see what it all boils down too after the reconstruction...I use it and like it.

Re:fp?

[Anonymous Coward]

promising!?! It's the greatest mediaplayer released ever... What are you missing? It plays just about anything as it is.

omg fp

[Anonymous Coward]

FP!!!!! KEKEKEK hahhaa

Re:omg fp

[Anonymous Coward]

You lose! Fecker!

Re:omg fp

[Anonymous Coward]

Are you that dude in the Lobby on Soulseek who always spouts out "KEKEKEKEKEK" at seemingly random moments? Just wondering.

Fox and Friends

[Anonymous Coward]

Fair and Balanced.

We report. You decide.

Fox News

Attitude

[Anonymous Coward]

Let's hope with his leaving, the mplayer developers lose their attitude problem somewhat. It has always been a displeasure to deal with such arrogant pricks, even if they do make such useful software.

Re:Attitude

[SilverSun]

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

Re:Attitude

[Anonymous Coward]

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.

He finally realized that he's been piling up shit for the last few years and now it's time to duck-and-cover. I just hope that the others will do the same and MPlayer will finally die (like it should have done a long time ago).

Re:Attitude

[IamTheRealMike]

Maybe this disruption of MPlayer development can also be seen as a chance for a more unified default mediaplayer for linux, i.e. xine.

Hrm, be careful what you wish for. Xine may be nicer than MPlayer codewise but IMO GStreamer is nicer than Xine, as well as being powerful, with lots of promise.

There are still some things that need to be done with GStreamer before you could say recreate Xine - it needs interactivity support for DVDs etc.

Long term though it's pretty obvious that Xine and GStreamer are going to compete for the multimedia framework - I have no idea if that's bad or good.

Re:Attitude

[moncyb]

The output mplayer sends to stdout is still a incredible mess.

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.

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.

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 this disruption of MPlayer development can also be seen as a chance for a more unified default mediaplayer for linux, i.e. xine.

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.

The one thin xine is lacking is an encoder a la mencoder.

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.

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.

I don't share your confidence. Keeping the code and design clean takes time. Yes, it is good--especially for the long term, but it does not speed up development. Fast development will usually cause messy code and lots of hacks. This may be the reason mplayer is in its current state--in fact, if you look at the linked mails, A'rpi seems to say that.

Re:Attitude

[Anonymous Coward]

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!)

Re:Attitude

[labratuk]

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.

Re:Attitude

[Dicky]

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.

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...

Re:Attitude

[Anonymous Coward]

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?

Congrats to the MPlayer team!

[Longinus]

.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.

Re:Congrats to the MPlayer team!

[October_30th]

it's always nice to have examples of open source software that so readily stomps into irrelevance its closed source competition

By using closed source binary codecs stolen from proprietary closed source programs?

Re:Congrats to the MPlayer team!

[Longinus]

MPlayer ability to play hacked codecs is indeed a nice feature, but there's so much more the love about it, especially in the realms of performance (extremely low CPU usage), interface (sweet, sweet, command line, anti-aliased subs and osd), and flexablity (lots of other programs use mplayer, like MythTV and the mozilla-mplayer plugin that allows Linux users to watch movies in their browser). MPlayer manages to do a crap load of things without being bloated or slow.

Re:Congrats to the MPlayer team!

[vandan]

By using closed source binary codecs stolen from proprietary closed source programs?

It depends on what you're trying to achieve. If your first priority is to make a movie player / encoder package for Linux that rocks, then you may have to make compromises with your purest vision of open source technology, at least for a period.

Of course each person has the option of not downloading and using the windows binaries, but I will guarantee that for those who use mplayer as their main video player, when they have the choice of using mplayer's .dll loading capabilities or switching to another video player that has a native linux decoder, they will stick with mplayer. It's nice to have ideals, but when you're watching a movie, you care more about how the movie looks / sounds than whether you have win32 dll loaded.

Re:Congrats to the MPlayer team!

[Kynde]

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.

Not trying to bash mplayer or anything, I used for quite some time, but how about Xine ? I switched over a few months back and I've been more than happy with that.

I think the approach in Xine is more *nixy like with the marvellous lib and multiple UIs. But that's just my 2 cents...

Re:Congrats to the MPlayer team!

[Anonymous Coward]

I'm slowly managing to break my addiction to slashdot thanks to retards like you, but I couldn't resist this one last time. You may not have bothered to look, since you're a retard and all, but mplayer *is* library based, and does have multiple UIs. Also, unlike Xine, it doesn't crash all the damn time, and playing a DVD isn't UI voodoo.

I don't mind you commenting, but do try to use your brain a little. It just makes things nicer for the rest of us.

Re:Congrats to the MPlayer team!

[13Echo]

Low CPU usage is an understatement. I can play fabulous looking video in almost any format with no more than around 2% CPU usage on my Athlon 1400. It's very well designed. Just give it a good video card with appropriate XV support, and it flies. And it's got to be the most stable player out there.

A'rpi, thanks for all of the work that you've done. I'm sorry that you've missed out on a lot of free time, but your work is deeply appreciated by many. You've helped take the frustration out of Linux video. And it's nice that I have a means of listening to those NPR audio streams too. I wish you the best of luck.

Re:Congrats to the MPlayer team!

[Kourino]

... that only work on one platform? It still annoys me greatly that mplayer runs extremely well on my Pentium 3, but, depending on the task, absolutely crawls on comparable hardware from other architectures, or just plain doesn't support stuff at all.

mplayer? Plays everything? You obviously don't use powerpc-*-linux or alpha-*-linux :3

Re:Congrats to the MPlayer team!

[YrWrstNtmr]

It's nice to have ideals, but when you're watching a movie, you care more about how the movie looks / sounds than whether you have win32 dll loaded.

So what you're saying is, that it's ok to cuddle up to software from the EvilOne(tm) as long as naked chicks look ok on your screen, ideals be damned.

Re:Congrats to the MPlayer team!

[Progoth]

but mplayer *is* library based, and does have multiple UIs. Also, unlike Xine, it doesn't crash all the damn time, and playing a DVD isn't UI voodoo.

mplayer crashes for me constantly.
xine never does, and I'm running beta versions.
mplayer has no dvd menu support.
xine does.
mplayer craps out on fullscreen with xinerama.
xine gives you the option of crapping out like mplayer (spreading across both displays) but defaults to normal behavior (fullscreen on one display)
xine is easy to use
mplayer is not
half the time mplayer won't play sound, especially with QT
xine always does

anyway this is all just my own personal experience. I keep mplayer around, I'm now upgrading from rc5 to .90. but it barely seems worth it. I don't need its encoding stuff, and I've never run across a format I wanted to watch that xine couldn't handle. I don't know if it does RM or not, but I use realplayer for that anyway (and before you scream about closed source....that's one of the formats mplayer uses a closed dll to play).

oh and about playing a dvd being ui voodoo....whatever that means....
1. put in dvd
2. click DVD button
3. click Play button

doesn't seem too hard to me.

last time I tried to play a dvd with xine....it was an rcX...I seem to recall something about -dvd and maybe having to specify the chapter, or something? I don't recall if it even read encrypted dvds....anyway movie playing is decidedly a "Desktop Machine" function. all my file management is done in a console, most of my time is spent there in fact....but I don't want friggin command lines on my movie player. apps like that are supposed to be straight forward and easy to use: here's a movie, play it. screw mounting a dvd, finding which vobs are the biggest, and specifying the title on the commandline. (and it's the same with vcds....and of course a click of the VCD button in xine).

so anyway if you haven't tried xine in a while, give the newest beta a try. there's some bugs, but really, it's a stellar application. if you're happy with mplayer, fine. I think it's silly for there to now be a holy war over movie players. I haven't had good experiences with mplayer, but there's plenty of people who have. anyway....I encourage anybody to give them both a try, and now it's time to stop wasting time on slashdot ::grumble::

Re:Congrats to the MPlayer team!

[Anonymous Coward]

mplayer? Plays everything? You obviously don't use powerpc-*-linux or alpha-*-linux :3

Yes, obviously. Duh. What, you think running Windows on powerpc or alpha is going to solve anything? And yes, I'm quite aware that there is no Windows for powerpc...

Re:Congrats to the MPlayer team!

[Anonymous Coward]

In addition to our beloved kernel [kernel.org], it's always nice to have examples of open source software that so readily stomps into irrelevance its closed source competition.

Yes, by only donating 8-16 hours of your weekend, you too could play DVDs and Divx movies on your Linux based workstation! Windows sucks, blah blah, sure, but I don't need to compile shit and download illegal codecs to play DVDs on it!

Re:Congrats to the MPlayer team!

[otis wildflower]

Just to chime in:

I can rip 4:3 pulldown DVDs (23.976fps) at 700kbps at about 32fps on my Athlon 2400xp/nforce1-220 rig.. WHILE SIMULTANEOUSLY PLAYING THE OUTPUT FILE. AT 1920x1200.

Granted, I passthru the audio since I can only get halfway decent compressed audio sync using multipass encoding for which I have little time or patience, but 192kbps AC3 is small enough for me..

Needless to say, I'm impressed and grateful.

Plus, I use the xine skin on gmplayer, works OK enough for me.

Re:Congrats to the MPlayer team!

[jandrese]

I know I'm feeding the troll here, but...

How can you "steal" a codec that's given away for free? Just because it was used in a non-windows setting means they stole the codec? Granted some of the early DivX codecs were of dubious origin, but they were used in Windows as well, and nobody uses those anymore anyway (except in Windows).

Mplayer does what every good windows player (including mplayer2.exe) does, it incorperates as many codecs as possible from as many free sources as possible. Mplayer does make it a bit easier by including a big bundle of codecs though.

If you really hate the fact that it's closed source, why don't you join the FFMPEG team (which mplayer uses the codecs from) and start hacking? I'll enjoy my non-pirated[1] movies of nearly any format in the meantime.

[1] I know enough about troll logic to know what's coming next.

Re:Congrats to the MPlayer team!

[Kourino]

Of course each person has the option of not downloading and using the windows binaries, but I will guarantee that for those who use mplayer as their main video player, when they have the choice of using mplayer's .dll loading capabilities or switching to another video player that has a native linux decoder, they will stick with mplayer.

Wrong. Most of my computers can't run Windows binaries. (In fact, the computer I've come to use the most runs a PowerPC 750.) After all, not all the world's an x86. I'll take my native decoder, thanks. That way I can actually watch stuff.

Re:Congrats to the MPlayer team!

[Anonymous Coward]

At least not any newer versions of Windows. Oh the days of WinNT 3.5.1

Re:Congrats to the MPlayer team!

[SubtleNuance]

...using those closedsource binary decoders is out of necessity. Inventing a codec JUST so that you can implement it in proprietary software, and keep open-implementers at bay (in order to sell your dubious wares) is not exactly a moral victory.

Until the business model for Closed Media Formats disappears (by mplayer making making the decoder work everywhere (therefore no different than OPEN standards (so they loose the ability to differentiate))) im all for mplayer using those binary files.

foir instance: mp3 has no value, the more value fraunhoffer(sp?) asserts, the more appealing Ogg/Vorbis becomes...

Re:Congrats to the MPlayer team!

[Quixote]

Personally, I'd rephrase it like this:

it's ok to cuddle up to naked chicks, as long as the software from the EvilOne(tm) looks ok on the screen, ideals be damned

But thats just me..

Re:Congrats to the MPlayer team!

[technix4beos]

Actually, it runs on BeOS (Zeta) too.

I've seen it in action. It's flawless.

Imagine real time scrubbing through video. Loading up divx/dvd/mpg in under a second. Flawless sync. And more.

Re:Congrats to the MPlayer team!

[narfbot]

Of course each person has the option of not downloading and using the windows binaries, but I will guarantee that for those who use mplayer as their main video player, when they have the choice of using mplayer's .dll loading capabilities or switching to another video player that has a native linux decoder, they will stick with mplayer.

Um, I use MPlayer, not because of it's dll loading, but because it has the best _native linux decoders_. It can play everything natively, except QT6. I don't partically care about QT6 either.

Re:Congrats to the MPlayer team!

[shadowjk]

Xine rarely even plays a DVD, let alone display any menus of any sort for me, it seems to prefer deadlocking or crashing, even with Unencrypted DVD's!! MPlayer plays DVD's flawlessly though, mplayer -dvd 1, and it immediately plays, or decrypts and plays on the fly, without any need to click on icons in an unrealiable GUI which seem to alias half of the buttons with 'deadlock now', creating a virtual maze of "good" and "bad" buttons to click in the right order for anything to play.

Re:Congrats to the MPlayer team!

[revery]

maybe you should ask for a refund...

Re:Congrats to the MPlayer team!

[Anonymous Coward]

Imagine bugger-all software and a developer community roughly one-third the size of your average local LUG meeting.

Re:Congrats to the MPlayer team!

[Anonymous Coward]

...and what part of when they have the choice of using mplayer's .dll loading capabilities did you not understand?

Re:Congrats to the MPlayer team!

[Anonymous Coward]

Anyone tried QEMU to get the remaining codecs working? :)

Re:Congrats to the MPlayer team!

[joedavis123]

"By using closed source binary codecs stolen from proprietary closed source programs?"

Come on man, you know you shouldn't be bringing that kinda shit up.

No one around here cares unless its stolen from the zealots in violation of the GPL!

Re:Congrats to the MPlayer team!

[Kourino]

Nonono. I'm not really complaining about it. I know the limit of what I can expect as a consumer of free software. I'm just pointing out my opinion that maybe mplayer isn't the best thing since sliced bread after all. :3

Re:Congrats to the MPlayer team!

[Kourino]

I misread that bit. It's really that simple. Thanks, SlashBot! :D

Re:Congrats to the MPlayer team!

[revery]

I was taking a cheap shot anyway. Sometimes the lurre of potential karma gets the better of me.
Sorry about that.

THANKS ARPI!

[Anonymous Coward]

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!

Re:THANKS ARPI!

[den_erpel]

Next to this obvious cheering, it is a fact that mplayer is the most versatile player around that I can think of. I've seen lots of cases that mplayer is capable of player files with odd framerates (audio and video, mainly produced by a bad configured digital camera) while other (includeing M$ mplayer) players choked on it.

Since the license change, I've seen that (that allowed binary packaging) it is gradualy pushing other players to the background, exaclty due to it's versatility (aviplayer, xine, vlc, ...)

The documentation seems to be somewhat lacking and for some things I (still) use IMHO better tools:

video recording: nvrec, AFAIK mplayer does not support V4L2
encoding: transcode, mainly because transcode seems to have a much better doc and logical buildup of the options to transcode and large modularity (for filters). I use mencoder sometimes when transcode has problems with particular file (or used to)

One thing which no player seems to pull of correctly, is to play files with awfully synced audio, video...

Re:THANKS ARPI!

[irc.goatse.cx troll]

"You saved our day when there was no decent video player for Linux some two years ago. "
Because xine, xanim, and aviplay do not exist.
"MPlayer played a vital role in Linux's success. "
You say that like its bound to linux. Most linux distros do not include it (licensing issues), And those smart enough to get it working on their own could just as easily compile it from *bsd, or spend a little more effort and get it running in cygwin.

Re:THANKS ARPI!

[Anonymous Coward]

You brought us the Microsoft ASF fileformat support

No they didn't. We were using Avifile to watch those DivX;-)'s and ASF's long before MPlayer was a twinkle in a developers eye. Avifile was the original player to use Win32 codecs, too.

MPlayer is good, but it really was standing on the shoulders.

Re:THANKS ARPI!

[rjw57]

> You brought us the Microsoft ASF fileformat support

Wasn't that actually the libavifile guys...

Re:THANKS ARPI!

[Anonymous Coward]

No, it wasn't, and Mplayer's core strength for a long time was that it didn't use libavifile. Now it can. For a long time, libavifile sucked.

Jesus. It would be nice if you bothered to read up on the topic a little before mouthing off.

Re:THANKS ARPI!

[Anonymous Coward]

Chill out, fanboy.

libavifile certainly did support ASF before MPlayer. I know for a fact that before I had even heard of MPlayer, I was playing DivX;-) AVI's and the odd ASF with Aviplay. libavifile was also the first to support Win32 codecs, and was also the first to support DirectShow codecs.

MPlayer wasn't the first. Get over it.

Re:THANKS ARPI!

[Anonymous Coward]

MPlayer was the first. If YOU had not heard of it, it certainly not doesn't mean it wouldn't have been there. Check out the changelogs of MPlayer and Aviplay.

Moron.

Re:THANKS ARPI!

[Anonymous Coward]

"You saved our day when there was no decent video player for Linux some two years ago. "

Because xine, xanim, and aviplay do not exist.

You seem to have missed the word 'decent' in there.

Re:THANKS ARPI!

[molarmass192]

Here, here!!! Without a doubt, MPlayer is the most complete media player available on ANY platform and, yes, that includes Windows. I hope somebody as dedicated as Arp'i steps in to fill his shoes!

Re:THANKS ARPI!

[zurab]

encoding: transcode, mainly because transcode seems to have a much better doc and logical buildup of the options to transcode and large modularity (for filters).

I thought transcode used mplayer's shared post proc library too. Did they finally implement this on their own?

Re:THANKS ARPI!

[grazzy]

i remember things about very upset people screaming "ripoff,ripoff" when i hear this.. i might be wrong .. someone forgot to mention someone else in their grand release of a version capable of playing asf.. .

Re:THANKS ARPI!

[damiam]

Because xine, xanim, and aviplay do not exist.

xanim and aviplay suck and always have. Try playing Divx. A DVD? Quicktime? Windows Media? Any common internet format? Sorry, they don't cut it. Xine is currently around the same level as mplayer - they each have their strong points - but two years ago, it sucked just as hard as anything else. mplayer and Xine have shared a fair amount of code, and without one, the other wouldn't have gotten nearly as far.

Re:THANKS ARPI!

[Anonymous Coward]

I also want to thank ARPI! Without you, I could never figure out my gateway's MAC addressI!!

MPlayer rules...

[Anonymous Coward]

...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...

Re:MPlayer rules...

[Anonymous Coward]

> ppl who have time to waste with GUI and frontend development

...and is that because all real developers know that "user interface" and "frontend development" are a waste of time?

I do both, although like most code monkeys I have nearly zero talent on the UI side. However, I am personally getting increasingly tired of the attitude that "server side" and "backend" programming is the only path to real software.

/. btw, is popular for a number of reasons- one of which is that someone wasted time on the frontend.

Re:MPlayer rules...

[Anonymous Coward]

I don't even use the GUI at home. The arrow keys suffice for advancing the files, and the "F" key pops your pr0n into fullscreen mode with ease.

mplayer is *THE* best player

[mdew]

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.

Re:mplayer is *THE* best player

[Anonymous Coward]

No, xine is much much better. You're living in the 1980s, dude!

Re:mplayer is *THE* best player

[mdew]

xine is teh sux0r! hey freshmeat stats dont lie

well

[daserver]

Well Arpi is still there on the mailinglist doing stuff, he's just not the maintainer any longer.

Sound so familar

[jsse]

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*

Windows port?

[Majin Bubu]

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.

Re:Windows port?

[Anonymous Coward]

Have you even been reding the MPlayer homepage???

just install cygwin and you can compile the beast...

Re:Windows port?

[Xugumad]

According to the FAQ you can compile it on Windows using Cygwin. On the subject of ports, Mac OS X users may be interested in MPlayer OS X.

Re:Windows port?

[bodin]

If you need a really good mediaplayer on windows, mac or other platforms, please check out VLC http://www.videolan.org/vlc/ which is a VERY good alternative to both XINE and MPlayer. It plays video directly out of bin/cue-files and does all sorts of good stuff.

Free of course. Sister project is free videostreaming!

Re:Windows port?

[daserver]

MPlayer can also play video directly out of bin/cue-files. At least if it's a (s)vcd.

Re:Windows port?

[Majin Bubu]

Does it play:

-Quicktime files?
-Realplayer files?
-Win media files?
-DVDs?
-DIVXs?

Re:Windows port?

[Anonymous Coward]

Do you know what playes ALL this? Yes, that's right.

WINDOWS MEDIA PLAYER! And you don't have to spend a week configuring, compiling, setting it up and STEALING the codecs to make it work.

You Linux fanboys make me sick sometimes...

Re:Windows port?

[KAMiKAZOW]

Check out Media Player Classic or jetAudio.
Both player are able to handle all DirectShow codecs (incl DivX) as well as RealMedia, QuickTime, and also DVDs.
jetAudio installs the RealMedia codecs, but no QuickTime codecs. Media Player Classic installs no codecs at all (that's why it's so small).

Re:Windows port?

[Majin Bubu]

Stealing what? I already have the codecs because I have the appropriate programs. What I use to play a media should be my own business, as long as I own the media (I buy my own DVDs).

Re:Windows port?

[BJH]

Well, a case could be made that WMP is "stealing" the QT and RP codecs just as much as mplayer is...

Re:Windows port?

[Anonymous Coward]

For me, Media Player Classic hangs when trying to play DVDs on w2k. It works on wxp, though.

Re:Windows port?

[GlassUser]

Except that it regularly crashes, has bugs with screen rendering, and the interface is revolting.

Re:Windows port?

[Anonymous Coward]

No DVDs you ass ($$)
No encoding in MP3s ($$)
Bugging DRM at first

Want more?

Re:Windows port?

[Replicant7]

It plays all of these under Windows/Cygwin except Real, but this is in the works.

Re:Windows port?

[Anonymous Coward]

Do you know what playes ALL this? Yes, that's right.

WINDOWS MEDIA PLAYER

Since when?

When I last tried, WMP did not play realmedia nor quicktime AT ALL and DIVX only after hunt stolen codecs or the open source project codecs.

Hunting down a free quicktime and realplayer and a working divx codec pack took longer than downloading and compiling mplayer + accompaning codec pack.

Re:Windows port?

[Anonymous Coward]

Let me know when you get Windows Media Player running under Linux, dumbass.

Re:Windows port?

[viper66]

Not bad, but definitely limited in features compared to most windows players, such as sasami2k and zoomplayer.

Re:Windows port?

[antiMStroll]

Very nice but limited. No .avi support.

Re:Windows port?

[fliplap]

.avi is a container format that encompasses many codecs. For example, divx5 files are consider .avi when they are actually mpeg4

Re:Windows port?

[siliconwafer]

I agree with the parent. VLC blows Quicktime out of the water on OS X for casual viewing (pr0n, etc.) No messing with codecs, no slow load times, it just works. And works well.

POPULAR ACRONYMS AND CONTRACTIONS

[Anonymous Coward]

ASDA -> Associated Dairies
MFI -> Mullard Furniture Industries
TESCO -> Tessa Cohen (founder)

yes, exactly because of that

[DrSkwid]

Or would you prefer we were all MSN Subscribers rather than Internet Citizens?

Re:yes, exactly because of that

[October_30th]

I don't give a shit. I rather like Linus' using-the-right-tool-for-the-job attitude. If there is an open source alternative to closed software, that's fine and dandy. If there is no feasible open source alternative, using proprietary software is just fine.

I merely pointed out the hypocricy of calling MPlayer an open source revolution that stomps closed source into oblivion when its core performance is enabled by closed source (unlicensed) binaries?

Re:yes, exactly because of that

[Longinus]

"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.

Re:yes, exactly because of that

[Anonymous Coward]

open codecs like XviD anyway

Please use DivX5 in the future. Thnx.

Re:yes, exactly because of that

[Anonymous Coward]

fine and dandy

YOUR SO GAY!

Re:yes, exactly because of that

[Anonymous Coward]

DivX is in no way open. Thnx.

Re:yes, exactly because of that

[fferreres]

Prome is sometimes using the right tool for the jobs hampers and alter the path and progress other projects can make. If nobody feels the need for a good native decoder then progress will be slower, and Microsoft may sue / whatever and you are left with neither ham nor sausages.

You have to think of the hidden risks of every action. You need to take into account all the pros and cons. Of course it's better to just not care and use the win32 binaries. Nobody will complain now, but some time from now we may, and will be unable to complain. The world is not unfair, actions have consequences.

For example having used Win95 because it was bundled, and then Office because you could use your friends illegal copy has brought me a lot of trouble.

Re:yes, exactly because of that

[Zorikin]

> DivX is in no way open.

What about FFmpeg's libavcodec? In addition to supporting DivX 4/5 (and DivX 3, and others) for both encoding and decoding, it is open, efficient, stable, goes great with MPlayer, and it runs on your ppc hardware.

Re:yes, exactly because of that

[Anonymous Coward]

In this case there is no reasonable alternate path. Do you feel like reverse engineering all these proprietary codecs? Didn't think so. Besides, we need something now, not 5 years from now.

Re:yes, exactly because of that

[Phexro]

And is a GPL'd implementation of a patented compresson algorithm, which you must still pay fees to use, in the form of royalties. Just like MPEG 1 Layer 3, and the situation with LAME or any other F/OSS MP3 encoder.

FFmpeg and XviD are great, but they are not "free" in the RMS sense of the word.

Re:yes, exactly because of that

[crizh]

Assuming you live in a jurisdiction that allows algorithms to be patented.

Re:yes, exactly because of that

[Anonymous Coward]

That comes as a real shock as a Mac OSX user that uses mplayer often to play videos. What are these 'closed source binaries' you speak of?

Re:yes, exactly because of that

[fferreres]

I was not talking about this case, but that for each case you need to take into account the hole path of consecuences. Of course in this case, reverse engineering is AOQ.

Embedded Mplayer

[mrsev]

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.

Re:Embedded Mplayer

[The J Kid]

There is also an embedded Gnome 2 Mplayer called: Lumiere.

It's just started, but already usable and quite nice. Very promissing.

Re:Embedded Mplayer

[the_real_tigga]

there is a package called mplayerplug-in which provides a plugin for all netscape-compatible browsers (including opera).

Man Player 0.90

[Anonymous Coward]

Man Player

We dropped our pants. Ike got down on his knees and sucked me until I was hard and good and wet before he stood and turned.

"C'mon boy, Shove that pretty cock up old Ike's tight, brown hole and massage old Ike's prostate.

Ike bent forward and gripped the edge of the potting bench. The lean, white cheeked buttocks parted slightly and exposed the dark brown, crinkly, puckered star of his asshole "Now you go slow and ease it along until you've got it all the way in," he cautioned. "This old ass craves your young cock but it don't want too much too soon. You've got to let this old hole stretch to accommodate you."

"Are you sure you want to do this?"

"Easy boy, easy," he cautioned. "You feel a lot bigger than you look. Put a little more spit in your cock."

"It's awfully tight. I don't know if it's going to go or not."

"It'll go," said Ike. "There's been bigger boys than you up the old shit chute."

I slipped in the the last few inches.. "It's all in."

"I can tell," said Ike. "Your cock hairs are tickling my ass."

"Are you ready," I asked.

"How are you liking old Ike's hairy asshole so far?"

"It's real tight."

"Tighter than your fist?"

"Might be."

"Ready to throw a fuck into a man that reminds you of your grandpa."

"I reckon."

"I want you should do old Ike one more favor."

"What?"

While you're pumpin' my ass, would you reach around and play with my dick like you would your own? Would you do that for an old man?"

I reached around and took hold of his hard cock sticking out straight in front of him. I pilled the skin back and then pulled it up and over the expanded glans. I felt my own cock expand inside him as I manipulated his staff in my fingers. I imagined that my cock extended through him and I was playing with what came out the other side of him.

"C'mon, boy, ram that big cock up the old shitter and make me know it. God Damn! tickle that old prostate and make old Ike come!"

I came. And I came. Ike's tightened up on my cock and I throbbed Roman Candle bursts into that brown hole as I pressed into him. His hairy, scrawny ass flattened against my crotch and we were joined as tightly as two humans can be.

"A man's not a man till he's cum in another man." said old Ike. "You made it, boy. But still, a man's not a man till he's had a hard cock poked up his ass at least once."

Every time I think of that scene, I get another hard-on. Then I remember the next day when old Ike returned the favor.

I never have managed to come that hard again. If only Ike were here.

will it lose the race against xine?

[Pivot]

From his second posting;

> IMHO mplayer is good enough now that it won't lost in /dev/null if i leave.
> > Probably not, but will it lose the race against xine?

imho we lose it already. see xine, its popularity started to grow since a month and keeps growing. while we spend our expensive time by rev. engineering codecs, optimizing code, writing demuxers, they improve the gui. then they 'steal' the others and win. we have no chance against xine... Ah, stability. Yes, in old days mplayer was rock solid while xine crashed at every second click. It has been changed: mplayer is now everything but stable (thanks to that many hacks and 10l bugs), while xine improved stability a lot...

Re:will it lose the race against xine?

[Nadir]

I don't think this is fair. I seem to remember that it was the Xine guys who worked out the SVQ1 format...

Re:will it lose the race against xine?

[KeyserDK]

Well, gstreamer might win the support from the desktop projects instead of xine. It's already used by gnome, and i think the kde guys are looking into it too since the c++ bindings were quite nice. Lets hope that gnome/kde just decide on one thing to use for multimedia architecture =)

Re:will it lose the race against xine?

[rjw57]

And it was the xine guys (erm... OK hands up, me) who first separated the DVD nav stuff from Ogle sufficiently to be used in other projects (including, now, mplayer).

Re:will it lose the race against xine?

[Anonymous Coward]

Um, but you didn't actually write the DVD nav from scratch; by your own admission, you took the code from Ogle and reworked it.

Either way, thats hows OSS works, and we're all the better off for it: We have two good media players (MPlayer, Xine) under Linux/BSD/Others.

Does anyone have a timeline of the various media players? Its obvious that most modern players drawn on a huge number of sources E.g. xanim, avifile, Ogle, libmpeg etc. It'd be interesting (Well, maybe) to see how they all relate to each other.

Re:will it lose the race against xine?

[Anonymous Coward]

Yet, strangely, that's what the GPL is all about. These guys are assholes, I'm glad he's gone.

Re:will it lose the race against xine?

[Apreche]

The trueness. I use Xine because it has an easy GUI, it plays all types of files well without me having to do anything special. It comes with my distro. Oh yeah, it has a GUI.

This is a public service announement. There are two types of open source projects out there. The first kind is the kind where someone will write software for themselves and share the source to be nice and help others. The other kind is where someone writes software they want lots of other people to use and they develop it using the open source model.

If you are making the second kind of software you need to make a gui. You need to make an easy installer. You need to think about all the things a closed source company thinks about. The way I see it there are very few of the second type that have succeeded. gaim, Mozilla, CDex, DC++. That's about it. Every other piece of OSS has failed miserably in some way.

mplayer is one of those that has failed. I know how amazing it plays video. But the effort of making it work is greater than the benefit of using it. It should come in a single executable file that installs it. It should then have a GUI that works no matter what and never crashes. And it should play everything out of the box. It doesn't, so it is the loser.

Re:will it lose the race against xine?

[Silh]

While having used both xine and mplayer a fair bit for a while now, the one thing I really like about mplayer is the ability to control it from the console you start it on, without having to use a GUI or physically be on the system that it's displaying on (not having any type of IR remote control myself). The keybindings are nicely tweakable, which makes control of it from the keyboard easy (though I do like xine's ability to jump to the 10%-90% position in the file just from pressing 1-9). Some people such as myself don't appreciate GUI's as much, and being able to ssh over to the box across the room and play a movie, pause, seek, etc. in it without having to sit in front of it is nice.

Also, not everybody spends all their time in X all the time; much of the time I'm on a plain text console, and being able to play on fbdev is quite welcome as well.

Re:will it lose the race against xine?

[Thnurg]

Ah, but this is the beauty of Free Software. Xine did not steal. They re-used code under the terms of the MPlayer license.
If both packages had been proprietary then we'd have two players. One with a sucky UI, and one with sparse codec support.
MPlayer has not lost. Everyone who wants to use or develop a Free media player have won.

Re:will it lose the race against xine?

[SuperBanana]

while we spend our expensive time by rev. engineering codecs, optimizing code, writing demuxers, they improve the gui. then they 'steal' the others and win. we have no chance against xine

As usual, he's got a major chip on his shoulder. It was always one thing or another:

-compilers that caused the program to crash or do odd things(mplayer's configure script would refuse to run unless you had certain versions of GCC, and no- it wasn't 'the broken one that shipped with redhat' that it would object to). Funny, but nobody else had such unusual compiler requirements.

-licensing problems(some of the rants are truly spectacular.) At one point he went and dug up other projects that he felt were worse violators, as if to try and shift people's attention/justify his own problem. It was pathetic.

-Distros "incorrectly building" the player(I think it was how they were linking to libraries), which would then send floods of users to them(and, of course, they think all their users are idiots). Mplayer is by far the most anal-retentive about distribution of binaries, and as a result, the distros have told them to kiss off distro-style(ie, mplayer's been dropped from the major distros)

Mplayer got a bad review for (surprise!) having "developers [who] were unfriendly and ... documentation incomplete and insulting." His response? He attacks the author of the review with several bullet-points in the DOCS TO MPLAYER ITSELF! As someone once told me, "it's better to keep your mouth shut and let people wonder if you're an a jerk, than to open it and remove all doubt."

In each case, it was "mplayer versus the world", and in his opinion, the world could go screw itself. The docs, the website, even the messages in the configure script and the program itself- were all confrontational, and/or insulting; sorry, I don't like software that cops an attitude. This guy, if not the entire team, had serious problems with keeping their mouths in check. So, when I hear he's leaving, I can only say GOOD.

As I download this latest release, I can't help but remember how nothing changed with each release candidate up to this; the volume control doesn't work, the OSD is broken, some files give it complete conniptions but play fine in Xine, and it takes an enormous amount of CPU power now. Used to take about 2-5% of my CPU, now it takes 50%. Playback is jerky, too. Xine? None of these problems(sync is often better, playback is smooth, CPU usage is minimal/non-existent.)

Maybe the reason he's pissed off is because Xine is using his code(as they can- if you didn't like the concept of others using your code, you shouldn't have made the project open-source), but using it -BETTER-.

Re:will it lose the race against xine?

[Anonymous Coward]

emerge mplayer
or apt-get install mplayer

not really that difficult. it has played pretty much every single file ive thrown at it. mplayer rules.

Re:will it lose the race against xine?

[yugami]

>Funny, but nobody else had such unusual compiler
>requirements.

except for QT, and KDE. G++ was broken as of 3.0 up untill 3.2. known, documented bug.

Re:will it lose the race against xine?

[Dave_bsr]

urpmi mplayer. it's in mandrake 9.1

thank you, the Mandrake Guy will be here all week...

Re:will it lose the race against xine?

[HuguesT]

Please judge a developer primarily with the quality of his/her code.

That good old Ar'pi has one or many chips on his shoulder does not worry me in the least. On the other hand not having mplayer and mencoder anymore would make Linux a less pleasant experience.

People don't choose to use Windows and Word due to the inter-personal qualities of William H. Gates Junior.

How MPlayer is better than Avifile?

[Anonymous Coward]

I've used Avifile in the past and it worked well.

Re:How MPlayer is better than Avifile?

[Anonymous Coward]

ffmpeg/MPlayer basically takes the stuff that Avifile did so well (Win32 codecs, ASF/WMV decoding) to the next level; native codecs, a whole bunch of new formats (Including Sorenson Quicktime), DVD nav, streamed files etc.

MPlayer = Avifile ^ 3

I note with interest that Avifile is still being developed.

I just completed downloading it!

[Xpilot]

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...

Re:I just completed downloading it!

[13Echo]

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/

should suffice for a Slackware 9 system (It's what I use). Be sure to put your codecs in /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.

Re:I just completed downloading it!

[BJH]

Just remember to install FAAC/FAAD before the configure step if you actually want sound with your QT movies...

sync issues

[Anonymous Coward]

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.

Re:sync issues

[den_erpel]

mplayer, memcoder and transcode crash all on files where the audio video sync is terrible. I am not talking about 100 frames/samples, but about a 1,000 or more.

I had a number of such (nuppel) files, and wouldn't care if the quality of the audio was bad, as long as I had the files trancoded (the problem occurred in the first 1/5 of the file, the rest was perfect).

mplayer, mencoder, transcode all segfaulted (I assume some buffer which never should be filled, got filled anyway).

It has been a couple of months since I checked it, but I can reproduce the problem...

Re:sync issues

[BJH]

You might want to check again - I had a similar problem in rc4 that was fixed in rc5.

Re:sync issues

[Anonymous Coward]

Can you send the corrupted media file to MPlayer developer team? I'm sure they'll fix the problem very quickly.

Re:sync issues

[Anonymous Coward]

right, like he's going to send them video of him "helping a sheep over the fence".

Re:sync issues

[damiam]

Check it again, and if it still doesn't work with 0.90, please file a bug report. mplayer should not crash under any circumstances.

Re:Please

[ErikJson]

Yes. And we love it!

Seriously, ofcourse it had been better to do it in some other way, but what do you propose?

Hope this project doesn't fall by the way side

[sneakybilly]

This is by far the best Linux Media Player out. Plays all my pr0n :)

Re:Hope this project doesn't fall by the way side

[Erik K. Veland]

Also it's by far the best Mac OS X Media Player. Wait, VLC is probably the best, but not by far.

This close race is a Good Thing? in my book. Since the end user doesn't have to make a choice, but can keep any number of media players installed, the end user always wins :)

Re:Hope this project doesn't fall by the way side

[Anonymous Coward]

This is by far the best Linux Media Player out. Plays all my pr0n :)

Hmmm..
Windows Media Player = WiMP
Linux Media Player = LiMP

I'd rather LiMP than be a WiMP.

oh god that was corny... sorry

Re:Hope this project doesn't fall by the way side

[labratuk]

Plays all my pr0n

Yeah, I always found that xine crashed when it got to the scene with the marmalade and the parrot...

Idea for a new media player

[evilviper]

Strangely enough, each thread I comment on, seems to lead into a discussion relevant to a story not-yet-posted.

http://slashdot.org/comments.pl?sid=59962&thresh ol d=3&commentsort=0&tid=188&mode=nested&cid=5684 779

Basically, perhaps the best idea for a media player, is to work-out a robust, system-independant, plugin mechanism. That way, everything else (audio/video output, interface, etc) can be done seperately from the decoding/encoding. A media player is much more useful if you don't have to recompile it to add support for one more format. Windows Media Player, Real Player, and Quicktime all have the ability to download plugins, the only problem is that they are very-much system specific. If there was a system-independent plugin mechanism, there wouldn't be so much redundant work, with everyone doing the same things from scratch, for each player, and on each platform.

A media player on Linux, Windows, Mac, or even a hardware device, could all use the same plugin, which you can store along with your media file if you like.

The only thing that would have to be done for each platform, is to build a user interface, and write the native input/output calls. Sure, that's not so simple, but so much work is going into the codecs, that such a system would greatly simplify things. Just think, a Windows user could write a plugin for his video player, which you could then just copy over to your plugin folder, and play the same format.

One stiplation, it is very unlikely embedded developers will adopt a piece of software if it is under a license more restrictive than the BSD, so a reference implimentation would have to be BSD licensed. (The folks at Xiph.org understood that)

Re:Idea for a new media player

[Anonymous Coward]

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.

They're called "shared libraries". All you have is link into them and use the published APIs. :)

Re:Idea for a new media player

[rjw57]

The GStreamer project aimed to do this and xine already has support for demuxer, codec, output, etc plugins (indeed all the DVD features used by xine used to exist as a totally separate project at dvd.sf.net).

Re:Idea for a new media player

[MrMickS]

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.

Then we would be pretty much dependent on the speed of the CPU rather than any nice tricks that the different systems are capable of. Examples:

Apple makes uses of Altivec instructions in the G4 to get improved performance on the sort of ops that these plugins do.

SGI IRIX based systems make heavy use of the graphics subsystem (which is why they still command big bucks) for this sort of operation.

What you suggest wouldn't gain much approval from users as it wouldn't allow them to use the full power of the machines. Imagine having a system with a new graphics card and getting poor frame rates because the plugin didn't take advantage of the features of the card.

Re:Idea for a new media player

[Anonymous Coward]

You mean that it is very unlikely that embedded developers will adobt QNX? AFAIK, QNX has a license far more restrictive than BSD, even a proprietary, commercial license.

Re:Idea for a new media player

[groomed]

A media player is much more useful if you don't have to recompile it to add support for one more format.

Because new formats hit the market... Um... Maybe once a year?

If there was a system-independent plugin mechanism

There would also be no system dependant optimizations.

there wouldn't be so much redundant work, with everyone doing the same things from scratch, for each player, and on each platform.

The work is in figuring out how a file format works and how to decode it at fast as possible with the highest possible quality. Most of the rest is just preference, and you don't even want to generalize that.

Developers are very keen on the cost of even the slightest code duplication, but they rarely consider the cost to the user of having to hunt for and install the latest libraries, the small bugs that are caused by slightly different versions of libraries, and the tripling or even quadrupling of development time that it takes to produce solid resuable code.

Re:Idea for a new media player

[mdw162]

Yes, but couldn't support for all known codecs be compiled in without the codecs themselves? Obviously, certain files wouldn't play until the actual codecs were installed but it would save the hassle of having to recompile all the time. This would also eliminated the need for compile-time switches and auto-detects as everything would be "turned on" by default. Who cares if the resulting binary is twice as large.

Re:Idea for a new media player

[IronicCheese]

...wouldn't gain much approval from users...

to which, I do a spit-take and cry out:
Whha-a-a-a?

Windows Media Player, Real Player and Quicktime all use this architecture. Between them they have approximately 100% market share. There's a reality disconnect here.

The hardware-specific problem you talk about would go away if you had the proper hardware abstraction layer to write to.

Re:Idea for a new media player

[evilviper]

You miss the point. The pulgins are just going to define how to decode/encode the media. Each platform's players can choose what instructions are the most optimal for actually performing the actions.

Think 'codec markup language'.

Re:Idea for a new media player

[evilviper]

Because new formats hit the market... Um... Maybe once a year?

So how well is the DVD Player, hooked up to your TV, handling your DivX files you put on CD?

There would also be no system dependant optimizations.

Quite the opposite. You might as well say that, since HTML is system independant, it means no system-dependant optimizations for your browser.

Re:Idea for a new media player

[evilviper]

Platform independent means that you DON'T need to compile a plugin from source.

Are you saying that a single XINE/GStreamer plugin will work under Linux, FreeBSD, Windows, OS X, on any processor? I really doubt it (but I admit I don't have any experience with either project).

Re:Idea for a new media player

[Fnord]

There is no system for any media player where the same plugin binary works on multiple processors. You'd need something akin to java to do that and java is too slow to write a codec out of.

Re:Idea for a new media player

[evilviper]

There is no system for any media player where the same plugin binary works on multiple processors.

Nope, but there should be.

You'd need something akin to java to do that

That's not what I'm looking for. In other posts, I've called it a Markup Language for codecs. It should be possible to have the codec be nothing but a description of what computations need to take place, and each media player can decide which instructions would be best to perform the computations.

In fact, that's just what perl does... Except perl wasn't designed for multimedia processing, so it's definately not idea.

Re:Idea for a new media player

[groomed]

So how well is the DVD Player, hooked up to your TV, handling your DivX files you put on CD?

About as well as my VCR handles my DVD discs. The point being that no amount of flexibility in handling different media formats will allow for a change in form factor or other change in physical attributes. Which happens more often than you seem to think.

Quite the opposite. You might as well say that, since HTML is system independant, it means no system-dependant optimizations for your browser.

The thing is that "codec markup" needs to be expressed in some kind of language. If that language is too high-level, it becomes very difficult or even impossible to generate efficient code from it. Even in the unlikely case that somebody can get his "codec markup" compiler to be reasonably efficient, you would end up with more or less the same situation as today: some platforms will have superb "code markup" compilers, and some will have very bad ones, meaning that some players will be able to play certain content, and other won't because their "code markup" compiler is just too shitty.

On the other hand if your "code markup" is too low-level, you might as well have written the "codec markup" in machine language.

So you are just substituting one problem for another. And it still doesn't provide a solution for the case where the physical media changes.

MPlayer rocks!

[cdemon6]

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...

Re:MPlayer rocks!

[Anonymous Coward]

Why don't you put up a web page with your small scripts + short explanations of what they do/what to use? I know I would get inspired by something like that.

Re:MPlayer rocks!

[Anonymous Coward]

What tools are there to use the TV-out on nvidia cards in linux. I thought there were none - so I always have too boot into windows when I want to watch movies on the TV.

Please e-mail me at: slashdot@magnus.infidyne.com

Re:MPlayer rocks!

[Fledsbo]

NVTV works great for me (in combination with xine/mplayer)

Re:MPlayer rocks!

[cdemon6]

I'm just using XF86config-files, they are copied
oer by scripts, one includes:

Section "Monitor"
Identifier "Monitor0"
HorizSync 30-50
VertRefresh 60
Option "TvStandard" "Pal-G"
Option "ConnectedMonitor" "TV"
# Option "TVOutFormat" "SVIDEO"
EndSection

Has Slashdot made me gay?

[Anonymous Coward]

I've been on the internet since 1992 and I can remember time when gay sex (photos or stories) made me gag.

Ever since I started reading Slashdot (around 1996) I feel I've become more and more desensitized to gay sex and these days, to my horror, I actually get aroused by some of it.

So my questions is: can a weblog make you gay? I mean, if I keep reading Slashdot and posts like the parent, will it eventually turn me into a cum-slurping cockgobbler that thinks nothing but how to get his tight ringpiece around a thick, fat male cock.

Re:Has Slashdot made me gay?

[FUCKING FAG]

Absolutely!!!!

MPlayer is fantastic!

Re:Has Slashdot made me gay?

[Anonymous Coward]

Yes. Slashdot is a girl repelant. For some there is no choice.

Gstreamer (and xine?)

[KeyserDK]

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.

Re:Gstreamer (and xine?)

[groomed]

I think the last thing the world needs is another media framework. Not that it's a bad idea per se, or that gstreamer is bad. But there are too many perfectly good frameworks already. And they all have one thing in common: while they promise ultimate flexibility and all kinds of ubercool features, in practice, only a few combinations of plugins work really well. And even those would have worked better if they had simply been integrated into a single app.

What we need is code that does heavy lifting. Code that can read and write all sorts of file formats and that can do so at blistering speeds. But that requires mindnumbing attention to detail and painstaking testing on a wide range of different files and machines. So that most people prefer to indulge in the fantasy that all of this difficult work will just somehow evaporate, just as long as there is a good framework: "it's the bureaucracy, stupid". Of course, that rarely, if ever, pans out. At best, the grandiose Framework is reduced an API for manipulating media clips (QuickTime). At worst, it forever remains a flaky research project to satisfy the will-to-power of a few geeks and true believers (http://www.sourceforge.net).

Now that last part was a bit flamebaity. But what I'm trying to say is that instead of spending time on developing a "media framework" that can do "every conceivable thing", is almost always better to spend your time considering which of those "conceivable things" actually makes sense: and implementing that.

Re:Gstreamer (and xine?)

[Anonymous Coward]

You're kidding here. You can't be serious.Every desktop needs a media framework.

I'm not saying this needs to be part of the desktop, but for anything that goes further than play-my-mp3-and-crash, you need a decent interface. Make an interface that plays more than one type of file and you've got the beginning of a framework. Make it generic so it plays a few types of files and has the ability to be extended and you've got a true framework. Xine and mplayer are frameworks too, more or less, GStreamer can just do more than them.

So you didn't want a framework? Yes you do.

So the question is what the framework should do and how generic it should be. mplayer is pretty nifty in that it is all-integrated, has no dependencies except some .dll's, and is bleeding fast. Xine is somewhere in between the two. GStreamer is obviously slower (and supports less codecs), but it actually can do video editing and all that. Xine is planning on that (google: enix). In his exit post, you can actually see that Arpi wanted something similar, more generic interfaces, separate input support (keyboard/joystick) from media support (avi/mpeg), etc. See where he's heading?

GStreamer!

I'm not saying GStreamer is perfect, it's far from it, has lots of bugs, is not 100% stable and misses features. But the framework is actually out there and it can do what mplayer and xine can do. It can just do more.

And yes, of course Linux needs a media framework, or do you really want to view the type of a media file before being able to play it using view-media-{avi,mpeg,quicktime}-{sorensen,divx,xvi d,mjpeg,mpeg,bla}?

Re:Gstreamer (and xine?)

[groomed]

Make it generic so it plays a few types of files and has the ability to be extended and you've got a true framework. Xine and mplayer are frameworks too, more or less, GStreamer can just do more than them.

This is stretching the definition of "framework" to the point where it becomes almost completely meaningless. I might as well say that the bash shell constitutes a "media framework" because I've used dd and cat to edit movies once.

In his exit post, you can actually see that Arpi wanted something similar, more generic interfaces, separate input support (keyboard/joystick) from media support (avi/mpeg), etc. See where he's heading?

Have you _seen_ the mplayer code? It is a mess. Nobody denies that it needs to be refactored. But there is a difference between modularizing parts of a program and gutting the program altogether, until nothing remains but an empty (but oh so beautiful) framework.

In the meantime, I've used the mplayer code dozens of times to perform many, many video related tasks for study, work, and entertainment. Because the code is so straightforward, it is very easy to add your own stuff or change existing stuff until it does what you want. So as far as I am concerned, mplayer *is* Linux' media framework..!

Re:Gstreamer (and xine?)

[Anonymous Coward]

> per se

Excuse me, but what does this mean? Would it change the meaning of the sentense if you left it out completely ?

Thank you.

Re:Gstreamer (and xine?)

[minkwe]

Its a mess and still straightforward !?! I don't seem to see your point exactly.

instead of making another from scratch..

[ciupman]

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

Re:MPlayer rules...but the parent doesn't.

[Anonymous Coward]

Insightful my eye. Mplayer can already be ran from the command line (man mplayer), and there are front ends for Mplayer (KMplayer for example).

Maybe we'll finally get some threading

[sanemind]

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.

Re:Maybe we'll finally get some threading

[Anonymous Coward]

I also have a SMP system, threading would be nice.. but here's a silly trick for you: use mplayer to decode the video/audio and pipe it back to a second mplayer process for postprocessing/deinterlacing/etc. Works nice. :)

Re:Maybe we'll finally get some threading

[Graymalkin]

I've wondered about this before as well, also having an SMP system running Linux. I'd like maybe a compile time option for threading (in the main code branch) so we could have threading while single processor users wouldn't be burdened by the context switch overhead. Thread safety now can also be useful down the line when Mplayer evolves a bit.

Re:Maybe we'll finally get some threading

[Caligari]

For your information, there is actually a fork of the main MPlayer which implements multithreading.

Not sure how good it is since I don't have an SMP system, but it does exist.

http://mplayerxp.sourceforge.net/

Ah, the boon that is Free Software. Have a problem with something? You can modify the source and fix it yourself!

Re:Maybe we'll finally get some threading

[sanemind]

That's not the problem. I don't have a problem with running out of CPU when merely -playing- something, it's when I want to do some heavy processing on something a V4L capture from live television [using my computer as a PVR]. Now THAT does take a lot of CPU [ffmpeg or XVID encoding], leaving not that much for the processing. Still, it might work. Use mplayer to play the stream [with effects] and pipe it to mencoder to encode it, which can run as a seperate task. I'll see if I can get it to work. Come to think of it, Thanks for the tip.

Re:Maybe we'll finally get some threading

[sanemind]

Looked into it a while ago. It seemed to have already fallen behind the main branch, and it didn't support mencoder at all, anyway [which is all I care about]

A'rpi ?

[dnaumov]

"How do I..." "RTFM IDIOT!!!11"

You mean THAT A'rpi ?

Re:A'rpi ?

[Anonymous Coward]

You mean THAT A'rpi ?

Why are you asking here, look it up!! lamer!!1!

Re:A'rpi ?

[Anonymous Coward]

"How do I..." "RTFM IDIOT!!!11"

You mean THAT A'rpi ?

I think that attitude is something that easily happens if you invest too much time and devotion into a project, especially if that project is really rather complex and draws the attention of a lot of newbies to Linux who want to watch vidz. If you're trying to focus on the development with hundreds of dependencies to keep in mind and every day you get the same "How do I.." FAQs on the mailing list, I guess you tend to go down the "It's in the docs, check the README file", "Please read the docs, it's all in there", "PLEASE read the docs, we didn't write them for fun" "READ THE GODDAM FUCKING DOCS!!" route rather quickly.

Maybe projects like this should have separate PR people who are not as directly involved with development but know enough about the project to hand out clues to newbies, keeping the coders free to focus on deeper things.

Re:A'rpi ?

[cymen]

I think part of the problem is that some developers just don't know when they should stop reading their user mailing lists or at least stop replying. I'm sure flaming people lowers the stress level but, even though they may be right, it simply isn't very productive when plenty of other people could do the flaming or the helping without the programmers being involved. Theo, from OpenBSD, is (or was) definately in the category of "can't let go" so his current reputation isn't all that surprising.

Re:A'rpi ?

[gmuslera]

I suppose that now MPlayer versions will get boring names... who else could name 0.90 version "The RTFMCounter"?

Re:A'rpi ?

[MsGeek]

Looks like someone is suffering from The Leet Disease.

I don't think that projects like this need separate PR people...I think people in the community need an attitude adjustment. Every n00b you blow off with "man man", "RTFM," "STFI," or any of those other lovely turns of phrase will be a n00b running back into the waiting arms of Microsoft. Because Microsoft understands that not only gurus use their software. Actually I'd prefer that the n00bs go running to Apple, because that's truly an example of a Real OS with a (mas o menos) n00b friendly interface. But hardware that's built like a Mercedes costs Mercedes prices. Most people are tooling around in Intel Toyotas and Athlon Nissans...some even are in VIA Kias.

We need to spend a little time studying how the Mac community treats newbies. Visit your local Mac User Group sometime. There are no snarls of "RTFM" there. You would find it instructive.

Re:A'rpi ?

[juhaz]

Let them run. It's their choice, sometimes things do require bit studying or work, you don't get anywhere excepting others will do everything for you.

Free/Open software works because users who contribute their time and skills and make software better. If people don't even bother to read documentation, those people will never bother to contribute to any project or otherwise help make software better either. We don't need them.

I'd rather see developers doing what they best do, coding, making software better, than using half of their (valuable) time answering stupid questions that have all been asked and answered million times before.

Obviously there's no need to be rude, but if something is documented, what the heck is wrong with telling someone that this has been already discussed multiple times and you should look there and here, just pointing where to look instead of doing it in behalf of them? They might even learn something, which is not the case with latter option.

Re:A'rpi ?

[Anonymous Coward]

But hardware that's built like a Mercedes costs Mercedes prices. Most people are tooling around in Intel Toyotas and Athlon Nissans...some even are in VIA Kias.

Hmm, looks like someone is suffering from The Leet Disease.

Lamer... My Intel Porsche will smoke your Mercedes any day, looks better, and didn't cost any more. STFU.

WTF is STFI anyways?!?

Re:A'rpi ?

[MsGeek]

STFI = Search The Fine Internet.

BTW, that Toyota or Nissan is a great car in its own right. Not fancy but it will run forever if kept up well. Actually even the Korean cars are doing pretty well, although there isn't as much of a database on their longevity as there is with the Japanese makes. Similarly, the VIA EPIA is a relatively new platform, without much of a history. My comment was not meant as a dig at all. Hell, my car is a 1986 Nova, which is Chevy badged but is in all but name a Toyota Corolla.

There are just a lot more luxurious fripperies on a Mercedes than on a Toyota or a Nissan. (Note: I am not talking about Lexus or Infiniti) A flat-panel iMac looks a lot sexier and has a more luxurious feel to it than a generic beige box. And for those who want the Lexus/Infiniti equivalents, there's always Voodoo Computer, Alienware and their like.

Re:A'rpi ?

[pnis]

I think you have a good point. It is understandable that getting the same question asked every day twice gets on the nerves - but one could realize that he has no obligation to answer those.

developers attitude...

[erroneus]

...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.

Re:developers attitude...

[Anonymous Coward]

...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.

Did you? If a developer tells you to RTFM it's because the answer is in TFM! Do you want the developer to come round and watch the video with you?

I had mentioned, as a user, things that should be addressed and they kept saying things like "use the CLI" for that. Utterly ridiculous.

Ridiculous eh? Are you referring to the fact that you got such an excellent application for nothing and your complaining? Thats ridiculous.

I would prefer developers to concentrate on making a feature work before they make the buttons highlight when my mouse rolls over. See that thingie with all the buttons? It's called a keyboard, it won't bite.

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.

You don't need to be a developer to be a project leader, all you need to do is complain to developers, which you seem more then qualified to do. Why not put your money where you mouth is? This is, after all, the beauty of OSS.

Re:developers attitude...

[Anonymous Coward]

Dude shut the fuck up. The parent post made a lot of valid points.

Re:developers attitude...

[BJH]

they kept saying things like "use the CLI" for that. Utterly ridiculous.

Hardly. It's common for a project with both a CLI and a GUI to have more functionality available via the CLI - it's just so much easier to add an extra option to the command line than to screw around with whatever graphical toolkit is being used for the GUI.

Re:developers attitude...

[Anonymous Coward]

Which ones, fucktard? Point them out for me, cause all I saw was a bunch of pussyass whining.

Re:developers attitude...

[Anonymous Coward]

Pussyass would be you posting anonymously on the Internet where you can be as discourteous as you please and not get a fist to the face for it.

Re:developers attitude...

[Anonymous Coward]

As opposed to your anonymous bitchass self?

Re:developers attitude...

[erroneus]

Excuse me for not making some points clear. The statement "RTFM" was part of the mailing list program, not a statement made by people all the time.

And need I remind you and any other anti-social developer out there that the purpose of the mailing lists like these is to make suggestions, report problems and otherwise provide feedback regarding the progress of the project. It's not meant as an ego-feeder or a means to degrade others with insults... though sometimes it just seems like that.

Re:developers attitude...

[HuguesT]

Actually Mplayer has excellent documentation. In several languages too, complete, and pretty accurate.

Everything of interest that I've seen in the mailing list has more or less made it in the documentation.

MPlayer is working fine, gstreamer not.

[G�tz]

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.

Re:MPlayer is working fine, gstreamer not.

[Anonymous Coward]

You can get a more modern motherboard/proc for like $15 now, maybe you should upgrade.

Re:MPlayer is working fine, gstreamer not.

[G�tz]

I've already ordered my new machine, but I wanted to point out the bad and unoptimized code of gstreamer.

If you want a framework embedded into your desktop environment, you don't want it to take up all your CPU power just to play some sounds.

Re:MPlayer is working fine, gstreamer not.

[Anonymous Coward]

I'll use GStreamer because it has a clean clear interface, not a typical media player interface. Mplayer continues the annoying interface.

That said, Gstreamer has an awful install for Mandrake and Redhat and less codec support than Mplayer, so I'm open to suggestions.

Re:MPlayer is working fine, gstreamer not.

[FooBarWidget]

It's work-in-progress. Of course it isn't stable or optimized yet.
But GStreamer's code architecture is a lot more modular than MPlayer. That's why I hope GStreamer will win in the long term; in the short term, MPlayer is fine.

Re:MPlayer is working fine, gstreamer not.

[IamTheRealMike]

Also, gstreamer is broken with i686 optimized glibc.

I'm pretty sure that hasn't been true for a while - the opt scheduler took care of that stuff.

THIS FP CLAIMED FOR THE KU KLUX KLAN!

[Anonymous Coward]

This fp has been claimed for the Ku Klux Klan! DIE NIGGERS! Fuck the niggers! Die! WHITE POWER!

Re:THIS FP CLAIMED FOR THE KU KLUX KLAN!

[protectr]

Moderators... please shut him out...

Re:THIS FP CLAIMED FOR THE KU KLUX KLAN!

[Anonymous Coward]

My fp has NOT, I repeat, NOT been claimed by some lesser troll. KNEEL BEFORE ME FECKER!

Re:THIS FP CLAIMED FOR THE KU KLUX KLAN!

[Anonymous Coward]

What a sad little fecking idiot you must be...

Re:THIS FP CLAIMED FOR THE KU KLUX KLAN!

[Anonymous Coward]

cry me a river, you sensible piece of shit

Re:THIS FP CLAIMED FOR THE KU KLUX KLAN!

[Anonymous Coward]

suck black cock, loser.

Re:THIS FP CLAIMED FOR THE KU KLUX KLAN!

[Anonymous Coward]

You FAIL it.

This first post is claimed for the Southern Poverty Law Center.

Long live Morris Dees!!! Die racist scum. Fucking subhumans!

Re:MPlayer rules...but the parent doesn't.

[Anonymous Coward]

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.

Awesome

[ThundaGaiden]

I've been using this player religously ever since
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 :D

This is definatly one of the programs that makes
my life a lot easier using linux

Re:Awesome

[Anonymous Coward]

They're flabbergasted at something, but it sure as hell ain't mplayer.

Re:Awesome

[Anonymous Coward]

My friend was a bit surprised whan I told him that I could play back WM9 files, with lower CPU utilization than under Windows. Then again, he's an XP loyalist, so almost anything surprises him.

MPlayer!

[OmniVector]

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).

FreeBSD ports (Re:I just completed downloading it!

[Anonymous Coward]

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.

Changelog?

[Anonymous Coward]

Does anybody have the changelog between rc5 and the final version? I can't seem to find it anywhere on their website.

The timing of the release could have been better..

[bushboy]

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)

hungary rulez bigtime :)

[Anonymous Coward]

check the hungarians out =)

Never used it, but udos to him anyway

[nurb432]

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..

stability

[gold collector]

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.

Good GUI?

[er_col]

MPlayer by itself is definitely a great program, but a good GUI would make it much better still...

There are already a few decent attempts, the one I like the most is KPlayer.

Re:Good GUI?

[TeknoHog]

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.

Re:Good GUI?

[Ghengis]

Hence the term "Good" GUI. A Good one, IMHO, will hide when not being used, and re-appear when the user tries to interact with it. That way, If you don't do anything with your KB/Mouse, you get your full-screen, un-cluttered movie display, but if you want to change something and don't want to remember dozens of hot-keys, then the GUI can re-apear upon user input to handle the user's requests and then disappear again after a couple of seconds of inactivity or upon user request.

Re:Good GUI?

[Adnans]

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

Re:Good GUI?

[otis wildflower]

A Good one, IMHO, will hide when not being used, and re-appear when the user tries to interact with it.

Apple's DVD Player gui is pretty good with this, though it could have an even more compact display mode..

media players need guis for the simple reason that a 'power user' (like, as I would presume, all of us here) would be comfortable with a playing media file (news video stream, Monty Python episode, etc) alongside a separate task.

Full screen is mandatory, for a theatrical presentation, but for incorporating video in day-to-day computing a GUI is mandatory too.

Re:Good GUI?

[soccerisgod]

Actually, it DOES have a gui.

If you download the source code and type ./configure --help, one of the first options is gui-related. You have to turn it on explicitely. Also I think there is a binary version available on the mplayer homepage that is gui-enabled. I don't use it at all though, so I don't know if it's any good. All I know is it has skins.

Re:Good GUI?

[Anonymous Coward]

There's an easy way to remember what a "Good" GUI is.

Windows has a "Good" GUI. Linux has a bunch of bitter developers who shun GUI work.

Re:Good GUI?

[Christ-on-a-bike]

The GStreamer player does this. It's very nice, although a little crashy. Go look.

Hooray for MPlayer

[Bartmoss]

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.

non-DVD subtitles?

[icoloma]

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 :))

Re:non-DVD subtitles?

[soccerisgod]

If this is any help to u, mplayer tries to open files with the same name as the movie file minus extension plus one of these extensions:

utf, UTF, sub, SUB, srt, SRT, smi, SMI, rt, RT, txt, TXT, ssa, SSA, aqt, AQT

Re:non-DVD subtitles?

[Junta]

This is why I like .ogm.... one file... all the streams, including the text ones.. For sub/dub combinationn, it cannot be beat...

Re:non-DVD subtitles?

[icoloma]

THANKS thanks THX thx zanks man.

Will try it. THanks for the advice :)

What's the Open Source Model?

[Anonymous Coward]

Is it 'Release Early, Release Often?'

> 459 days after the previous stable release

Indeed, Good Work Gentlemen!

Re:What's the Open Source Model?

[Anonymous Coward]

Your quote says it all:

> 459 days after the previous stable release

There has been numerous development releases between. At least have a point to make when your trolling.

Re:What's the Open Source Model?

[Anonymous Coward]

What have you done lately, asshole?

Mod parent up

[FooBarWidget]

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.

VideoLAN is very cool

[Gabriel Radic]

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.

'Nother drone LOST to greed

[Anonymous Coward]

Quick! Somebody do the queen to make up for the $-grubbing ... grub.

On a similar note...

[Jon Abbott]

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)?

Re:On a similar note...

[Jon Abbott]

Ahem... Make that meteorologist. I guess meterology would be akin to meter reading... :^)

You loose.

[Anonymous Coward]

Thanks for playing, you loose. From the MPlayer Changelog:

29.01.2001, mplayer v0.11-pre11

"streaming fixes, asf support pre, indeo5 fix
...
.asf file format detection added (no .asf reading yet!!!)"


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.

Re:You loose.

[Anonymous Coward]

OK, you did your homework. With a grain of salt I must admit that I lost.

okok...

[Lispy]

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

Re:okok...

[Bandman]

MPlayer doesn't really decode the media streams. It uses dll files for other operating systems which decode them. Basicly, in order to legally decode Sorenson, for example, you have to have Quicktime on a windows partition. To decode some Mpeg4 stuff, it uses native Windows DLLs, which to legally use, you must have Windows. At least this is the way I understand it. Because of this, MPlayer treads a fine line between legal and illegal. I believe it is GPL, or some other other Open Source license. The program would be distributable, but the files on which it mainly depends (not all, there are some public domain decoders included i believe) would not be. That is probably why alot of distros don't include it.

Re:okok...

[rzei]

To decode some Mpeg4 stuff, it uses native Windows DLLs, which to legally use, you must have Windows.
i don't actually think so, afaik all mpeg-4 video is decoded with lavc from ffmpeg project, which is is LGPL if i read correctly from their homepage. for mpeg-4 audio, there is an opensource decoder too, faad2. another good link could be mplayer's (excellent) documents starting from here or in DOCS/ in source dir.

-rzei

Re:okok...

[Anonymous Coward]

this is NOT true
it CAN make use of closed codecs if you have them on your system, but it does not rely on it.
Plenty formats are visible without this stuff (through, for instance, ffmpeg libs).

Mandrakes version for instance is (ofcourse) free of any ties to closed software.

Re:okok...

[Anonymous Coward]

Dude, you are very confused. MPlayer mostly uses native codecs from FFmpeg project and others. In some cases, nobody has figured out how to play a format, or doing so would be illegal. In such cases, MPlayer can also use windows DLLs to play such contents (Sorenson). In other cases (Real), they have a native decoder, but it's not perfect, so they can also use the dll if you want. But most normal formats (MPEG, DivX, XviD, MPEG4, even WMVs and such) are decoded natively, with GPL'ed decoders which run on most architectures.

Don't want to watch Sorenson? Cool, if you don't have Quicktime, you won't. But at least you have a choice. For the vast majority of stuff out there, there is a native GPL decoder for MPlayer. You do not need a single Win DLL to watch the vast majority of films out there (excluding Sorenson). I know cause I've never had them.

Re:okok...

[evilviper]

MPlayer doesn't really decode the media streams.

Umm, it does for the most part. Anything FFMPEG can handle, is natively decoded with MPlayer. For anything else, it loads DLLs.

Because of this, MPlayer treads a fine line between legal and illegal. I believe it is GPL

No. Actually MPlayer is very-much illegial. You haven't paid the license fees to MPEG-LA for MPEG2/4 have you? You are likely violating numerous EULAs by using the DLLs seperate from the application. In addition, because of patent restrictions on MPEG codecs in mplayer, it can't legally be distributed anywhere that MPEG2/4 is patented. That's right, the MPlayer folks are violating the very GPL they've released their code under. Reminds me of OpenSSL.

So much hostility...

[entrigant]

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.

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 ... 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!"

Boo Fucking Hoo

Re:So much hostility...

[swordgeek]

Hmm. What you say is true. There has to be a line drawn somewhere, beyond which you give up on the user being unable to RTFM. However in the case of mplayer, the developer is a spoiled four year old brat as well. Here's a direct quote:

"Unfortunately MPlayer is out of our control. It's used by lamers, Linux users who can't even use Windows, and never tried to compile a kernel."

Call that tech support? 'If you can't compile a kernel, you're not WORTHY of our player.'

I've not had any problems with mplayer--it works for me. However, the developer is an obnoxious jerk who seems to spend more time belittling users than he actually would spend helping them.

Re:So much hostility...

[Anonymous Coward]

I think that was a little harsh, I don't envy the guys position at all. If I had taken that much shit I would be bitter too and would have given up long ago.

Re:So much hostility...

[Trejus]

What makes it so difficult to treat the problem like spam? Just ignore those users. Why put your contact address up for users to find you if you don't really want to hear from them? And if it's a mailing list, why not just sit around and let someone else answer. Perferably someone who is not as bitter and cranky. The guy is making a movie player, what kind of target audience does he expect? When you make an app for the end user, you're going to get endusers. Not developers, not power users, but people who heard linux was cool/the next big thing/the best operating system ever/etc. and want to try it out.

I mean seriously, in what way does it help anyone to be rude? If you don't want to help, that's your right, but there is no reason to get pissy about it. It's a big project, let someone else deal with it.

Personally, i'm sick of seeing elitist crap like "well i read the docs and it worked just fine." Even the best of us have our moments of stupidity.

Re:So much hostility...

[BJH]

Elitist crap? More like sensible advice...

Honestly, WTF is elitist about reading the docs???

Re:So much hostility...

[Trejus]

I never said there was anything elitist about reading the docs. There is something elitist about saying "i read the docs and everything worked fine" because it implies the person with a problem is an idiot because he couldn't get it to work. Using statements like WTF and RTFM are inherently elitist. They imply that things are obvious. Unfortunatly, what is obvious to you, is not necessarily obvious to the person asking the question. Maybe that's why he asked it in the first place.

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.

Re:So much hostility...

[BJH]

There's little point in reasoning with you - you've already made up your mind, it would seem. I do suggest you go and get a good dictionary and look up the word 'elitist', though.

I might point out that you used expletives yourself, as well...

Re:So much hostility...

[Trejus]

Made up my mind about what? All i'm trying to say is that often times people get confused and it's not the best course of action to blindly respond to such queries with "RTFM," or a similarly rude statement. While there is some onus on the users to execute their part of the bargain, idealy, some effort should be made to help the ones who have acted responsibly, but still need help. If you don't want to take the time to figure out who is who, then your user base is better off if you don't bother replying at all. Let someone else do it. I'm having trouble seeing exactly what part of that you are objecting to.....

elisist - someone who believes in rule by an elite group ant: egalitarian (from Wordnet )

This is exactly what I'm talking about. The whole RTFM business is "once you know what you are talking about, you are allowed into our society." One of the earlier posters even mentioned how A'rpi complained because his project was in the control of the linux newbie crowd. How is that not elitism?

And according to American Heritage Dictionary, through Dictionary.com my use of the word "ass" to describe a stupidly self important person is not an expletive.

Re:So much hostility...

[BJH]

Last time I looked, 'fuck' was an expletive. Perhaps you should read your own post again.

Newbie revenge

[Anonymous Coward]

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?

Re:Newbie revenge

[Anonymous Coward]

apt-get -y install mplayer-093

Except that doesn't work, "E: Couldn't find package mplayer-093".

Re:Newbie revenge

[Anonymous Coward]

apt-cache search mplayer

build it from the source tho, its a lot better. more optimizations for your system.

i agree, if you want to build your easy install, all in one file binary, then go ahead, thats what free software is about, go make your installer with all the codecs then let people download it, but dont put that work on mplayer.

Re:Newbie revenge

[rifter]

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...

Re:Newbie revenge

[Anonymous Coward]

I've used nearly every release of SuSE to date and never had a single problem compiling/using MPlayer.

I'm curious how you've had so much trouble?

Re:Newbie revenge

[rifter]

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.

MPlayer no longer really depends on Win32 codecs

[Replicant7]

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.

Thanks to cygwin...

[Anonymous Coward]

...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 under Cygwin and MinGW

[Replicant7]

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.

Re:MPlayer runs fine under Cygwin and MinGW

[Majin Bubu]

With a GUI or from the CL?

Re:MPlayer runs fine under Cygwin and MinGW

[Replicant7]

CLI only, same as Cygwin. Somebody mentioned that he was working on a simple GUI, but no code was ever published.

here you are

[Replicant7]

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

finally realeased?

[Anonymous Coward]

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.

Oh come on...

[Replicant7]

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...

Re:Oh come on...

[Overly Critical Guy]

Looks like you're too late. Welcome to the consequences of these attitudes most Linux developers seem to possess. Disillusioned users.

Re:Oh come on...

[Anonymous Coward]

Give me some of what you're smoking! PLEASE!

Re:Oh come on...

[evilviper]

Holy !$%^*, I don't even know where to begin...

EDL System

[Anonymous Coward]

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.

Oh Please!

[Fefe]

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.

Re:Oh Please!

[Glytch]

At last, a voice of reason! I wish I had mod points right now.

Just speaking for myself, I like the nice and simple GTK frontend that's included in the Mplayer source tarballs, but I love the fact that it's entirely optional even more.

And to all you Gstreamer fans, ever try to satisfy all of Gnome's dependencies if you're not running Redhat/Debian/Mandrake/etc binary packages? Try compiling Gnome yourself and then we'll talk about how allegedly "great" Gstreamer is. I swear to god, "Gnome documentation" is the biggest oxymoron on the planet. Ten thousand pages all pointing to each other, none of which actually provides information on fixing problems.

Err, sorry. Didn't mean for this to turn into a rant, but oh well. Still mostly ontopic.

Re:Oh Please!

[Dave2 Wickham]

Not tried Garnome then? It really does make compiling gnome from source really easy.

yaaa for mplayer!

[Anonymous Coward]

this app kicks! i love it!

thanks for the great work guys! and here's to version 1.0!!!!!!!!!

cheers,

jonah

Xine vs Mplayer

[realnowhereman]

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.

Re:Xine vs Mplayer

[mdw162]

Well, I don't know your whole situation, but I'd guess this is a matter of not using the right settings for mplayer. There are 4 million options and they can get confusing as hell, but with all that means the ability to really optimize everything. You may need to use some weird combination of switches and play around with it a little but I'm sure it can be made to be as efficient as xine.

Re:Xine vs Mplayer

[fliplap]

Xine recently seems to have taken a few leaps and bounds as well.

The only reason..ONLY reason xine seems to have taken so many leaps and bounds is because the mplayer developer spend all thier time making sure stuff plays. The xine developers are more than happy to let the mplayer developers do that while xine works on the GUI, then takes the player code from mplayer to make videos play.

From the mailing list:
> > IMHO mplayer is good enough now that it won't lost in /dev/null if i leave.
>
> Probably not, but will it lose the race against xine?

imho we lose it already. see xine, its popularity started to grow since a
month and keeps growing. while we spend our expensive time by rev.
engineering codecs, optimizing code, writing demuxers, they improve the gui.
then they 'steal' the others and win. we have no chance against xine...
Ah, stability. Yes, in old days mplayer was rock solid while xine crashed at
every second click. It has been changed: mplayer is now everything but
stable (thanks to that many hacks and 10l bugs), while xine improved
stability a lot...

Re:Xine vs Mplayer

[fferreres]

I think I see the Xine + Mplayer efforts with great regard. I think mplayer is indeed more for the techy oriented and far more chalenging from a developer perspective than Xine. Xine is cleaner and doesn't pretend to be the discoverer of the holy grail. Kudos to both of them. No matter which one I use I know I works because of al the unintentional but *combined* effort out in both Player (I'd include Ogle also)

Re:Xine vs Mplayer

[BJH]

A couple of things to try...

$ mplayer -vo help

If you see any of these lines in the output,

xv X11/Xv
dga DGA ( Direct Graphic Access V2.0 )
sdl SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!)
vesa VESA VBE 2.0 video output
xvidix X11 (VIDIX)

try them in this order:

xvidix
xv
dga
sdl
vesa

Command format is 'mplayer -vo filename', where type is from the list above.

Apologies if you've already tried this.

Re:Xine vs Mplayer

[BJH]

Grrr... that should have been 'mplayer -vo type filename'.

Re:Xine vs Mplayer

[lmfr]

Actually, for DVD playback I prefer Ogle: http://www.dtek.chalmers.se/groups/dvd/

Till today it supported any DVD I inserted in my laptop and played them smoothly.

Re:Xine vs Mplayer

[pc486]

This is because MPlayer didn't move over to the new libmpeg2, like what xine did, so quickly. There were some design issues and other things that plagued the newer libmpeg2 releases and MPlayer worked with the libmpeg2 team to get these issues fixed. Just recently (within this past week or so) they upgraded the local libmpeg2 v.2.1 copy (hacked up version) to the latest libmpeg2 and ploped it into the CVS version of MPlayer. This late change allowed for all the preformace gains that libmpeg2 v.3.x has without jumping into a poor API or the compatibility problems too soon.

It's like the Linux kernels. Sure the (formally) new 2.4.0 came out and was "stable" but there still were some major problems that didn't get ironed out until the 2.4.9ish area. Arp'i and the MPlayer development team simply waited for libmpeg2 to stabalize their new release.

Point being, try out the CVS version of MPlayer! Testers are always welcome!

Re:Xine vs Mplayer

[evilviper]

Unfortunately, Ogle doesn't have any deinterlacing, so many DVDs are very difficult to watch.

In addition, for some reason, output to the VGA port of my notebook shows some lines through the picture when Ogle is in fullscreen mode. I normally wouldn't blame it on Ogle, but everything else, including MPlayer, works fine in the same situation.

Thanks Mplayer Crew

[ThoreauHD]

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.

user's attitude...

[PhoenixK7]

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.

Re:user's attitude...

[erroneus]

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.

Re:user's attitude...

[erlando]

Oh.. You didn't read paragraph 1337 section 8?

The USER will accept any and all abuse from the DEVELOPER of the SOFTWARE whether or not this abuse is justified. It is after all the DEVELOPER who has made the SOFTWARE. Tough sh*t! RTFM!

;o)

Re:user's attitude...

[KnightStalker]

If I develop any useful software, and I release it freely, that is damn well going in the license. :-)

Re:user's attitude...

[sir99]

How long ago was this? IIRC, you can do these things by putting the following lines in ~/.mplayer/config:

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>.

Yes, but...

[Lispy]

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.

Re:Yes, but...

[fucksl4shd0t]

If they would include the player without any closed libs or potential copyright conflicting source they could add a huge benefit to their distributions.

Yes and no, actually. Until recently, they couldn't distribute binary versions of MPlayer, and it was due to licensing of one of the libraries mplayer depends on (I think lav, but I could be wrong). Furthermore, now they can distribute binaries, and Mandrake 9.1 has one. The problem is, mplayer's build system automatically compiles and optimizes mplayer for your system. It detects cpu, math coprocessor, graphics card, etc. and optimizes for it. The binary distribution that comes with Mandrake is compiled with run-time CPU detection, which means that MPlayer is not optimized. I wound up uninstalling Mandrake's MPlayer and building it again, since it compiles very easily.

They should rename it.

[Anonymous Coward]

When I saw MPlayer, I, as well as many others I'm sure, thought of the shitty game service at www.mplayer.com ..

Mildly OT: Streaming video ?

[FauxPasIII]

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 ?

Re:Mildly OT: Streaming video ?

[Anonymous Coward]

MPlayer can handle MS Streaming video, if you have the dlls. My questions are these:

• I'm using kmplayer, is there any way to have a progress bar like quicktime and ms mplayer have so you can skip around the stream?
• Why does it take so long to recognize an asf stream? (Sometimes is takes ~10 minutes before it starts to play)
• How do I record the stream?

thanks

Re:Mildly OT: Streaming video ?

[Anonymous Coward]

Get Mplayerplug-in it will do what you are asking

Re:Mildly OT: Streaming video ?

[Nadir]

You want this: http://mplayerplug-in.sourceforge.net/

Read between the lines

[narfbot]

'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.

Re:Read between the lines

[dvdeug]

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.

Because the mplayer team is also actively hostile to distributions including mplayer?

Re:Read between the lines

[Anonymous Coward]

I have read all the posts on debian-devel and debian-legal. Debian seemed to be hostile and not mplayer.
The mplayer team just couldn't understand, why debian has rejected including mplayer in the distrib. Debian told something about legal reasons, but they didnt answer the arguments of the mplayer team.
I have read every available comment about Redhats gcc 2.96. Xine had to hack, as far as I know, the code to be compatible with that unofficial version of gcc. The mplayer team didn't do that. To include a compiler, that nobody else uses, in a distrib is like a well known companies strategy.
The mplayer team could not understand why some distribs (e.g. Suse) include a crippled down version in their distrib. They didn't get an answer, AFAIK.
Tons of users came to the mailing list with problems allready solved. The distribs version of mplayer was either crippled down, or had this madman "property" compiler.
As I know there is only one distrib, which contains mplayer in whole. UHU

Re:Read between the lines

[narfbot]

AC answers it exactly =) I've read all comments as well. Guess what, linux 2.5 now has a flag to disable certain code to not trigger the 2.96.

Some distros question the legality of some parts of MPlayer (while some include Xine in whole when they are almost the same code... like debian did) and this "legality" comes from the distros own intentions, and has nothing to do with MPlayer authors being hostile to binary distrobution. It's GPL anyways.

Re:Read between the lines

[dvdeug]

As I know there is only one distrib, which contains mplayer in whole.

Think about that statement. The distributions have no motivation to provide broken software to their users, so if only one distribution provides a whole mplayer, that's probably mplayer's fault.

To include a compiler, that nobody else uses, in a distrib is like a well known companies strategy.

The comparison to Hitl ... I mean, Microsoft is totally uncalled for. Anyone else could have used GCC 2.96, and in fact Debian did for the Itanium part of the distribution. RedHat chose to use what they thought was the best compiler for the job. Right or wrong, better or worse, that was their choice and they had to make it.

Debian seemed to be hostile and not mplayer.
The mplayer team just couldn't understand, why debian has rejected including mplayer in the distrib.

From what I've read of those discussions, mplayer has historically be a mess of bad licensing decisions. The fact that people nitpick what has been a historical source of problems is not surprising. The fact that the mplayer people could not understand it was because they weren't interested in understanding it; they'd rather attack Debian for not including mplayer.

Uh.

[Scott Francis[Mecham]

(not having mod points for the good anonymous reply)
"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.

Re:Uh.

[groomed]

Can you name me some on Linux? And keep in mind that we're just talking about MULTIMEDIA?

The point is not whether it works on Linux, the point is whether there is an open specification. And of those, there are zillions: OpenML, QuickTime, Java Media Framework, GNOME Media Framework, aRts. And these are just some of the most ambitious ones.

Now, after reviewing those links, you'll probably say: "but none of these works! none of them is finished!". And that's exactly my point.

I see a good "multimedia framework" to be the same thing as programming using the GNU tools.

Yes. And that's where you would be wrong. It a completely different thing. One works with text and symbolic representation. The other works with audio and video. There is a reason, you know, why all graphical programming languages to date have failed to gain widespread acceptance: it just doesn't work very well.

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.

Uh. While Mozilla is not actually a failure, -- owing more to some incredibly fortuitous circumstances (*cough AOL money cough*) than actual competency on the part of the development team -- Mozilla did fail to satisfy *almost every single goal* that it set out to accomplish. So, yes, why not compare to Mozilla? A slow, bloated, overbearing software project, that's years late? You don't even have to take my word for it: just ask Apple. Hell, ask the Mozilla team themselves: what is Phoenix other than an attempt to salvage Mozilla?

Truly, it's great that Mozilla exists, but the only reason why it's anywhere near useful right now is because the team, after years of overengineering, finally started to worry about how the thing was actually going to be used by actual people. Since that point (about 2 years ago), Mozilla has started to make some great leaps towards usefulness.

Re:Uh.

[Nodatadj]

GMF never got started,
GStreamer took over from it, had the same idea and more developer time, so it got to where it is.

GStreamer does actually work these days, plays most of my avis (has some issues with broken ones), all of my mpegs, all my audio (mp3, flac, ogg and wav), and I'm using it in my own audio editor program.

But so we shouldn't start an ambitious project because it won't get finished? Seems rather defeatist.

Re:Uh.

[groomed]

But so we shouldn't start an ambitious project because it won't get finished?

No -- I might have given that impression -- but: we should finish projects before moving on to new ones.

hmmm how odd..

[Anonymous Coward]

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.

ups & downs

[Anonymous Coward]

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 :-)

Ends vs. means

[Gothmolly]

The ends never justify the means.

improvements? like what?

[certron]

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.

Re:The timing of the release could have been bette

[nutbar]

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.

Good BS troll...

[Anonymous Coward]

All the mods with an IQ of less then 10 fell for it.

So what you are saying is....

[Anonymous Coward]

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!"

mencoder directly to VCD/MPEG1 or SVCD/MPEG2?

[Kevin Burtch]

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)?

The closest I've gotten (for VCD) so far is:

mencoder -tv on:driver=v4l:norm=ntsc:input=0:width=352:height=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

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=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.

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?

Re:mencoder directly to VCD/MPEG1 or SVCD/MPEG2?

[Abcd1234]

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.

Something like this should work (for VCD):

mkfifo stream.yuv
mkfifo audio.wav

mplayer <tv options here> -vo yuv4mpeg -ao pcm -aofile audio.wav < /dev/null &
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. :) OTOH, if you're running an SMP box, this technique is probably more efficient...

See ya!

[theLOUDroom]

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.

wasting slashdot time

[Dave_bsr]

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.

Re:wasting slashdot time

[Anonymous Coward]

you haven't tried the v1 beta versions, dvd comes with them. and they don't seem to ever lock on me...

Nah...

[Lispy]

Come on...i would never...would I?

Re:Oh come on...Upon a path.

[Anonymous Coward]

" 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.

Re:So much hostility...A passage to grief.

[Anonymous Coward]

"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.

Re:The timing of the release could have been bette

[Anonymous Coward]

are you actually asking devs to sync their release dates with the distro (package) makers?
sounds a bit M$ to me...

Re:Oh come on...Upon a path.

[Overly Critical Guy]

Get off the podium. You're being drowned out by our Windows Media 9 movie projection.

coders busy elswhere - Mozilla knows about this

[Wil63]

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?

Mplayer kicks ass

[FLoWCTRL]

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.

On the subject of GUI

[HuguesT]

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.

Legality

[jmorris42]

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.

Re:Legality

[evilviper]

1. EULAs have never been ruled as being unenforceable, although some terms have. It's a shaky legal situation right now.

2. That's true, but many people within the USA are using and redistributing MPlayer. Both of which are illegial.

Re:Legality

[jmorris42]

> EULAs have never been ruled as being unenforceable, although
> some terms have. It's a shaky legal situation right now.

The laws governing buying and selling things are pretty settled law. EULAs are a major departure and require major proof of legality. Which is why no company has tested a EULA in court, the emperor has no clothes.

So take a stand and don't bend over and take it from the megacorps. Yes that might mean being a victim, but if you aren't willing to fight for your inalienable rights you aren't deserving of the exercise of them.

Re:Legality

[evilviper]

So take a stand and don't bend over and take it from the megacorps.

Trust me, I don't. However, that doesn't cover everyone. I certainly wouldn't be willing to put such risk on a company I work for.