Slashdot Mirror
Mplayer Revisited
Joe Barr writes "It's been two years since I first wrote about Mplayer. Maybe the fury of the developers/community reaction to the fact that I dared to criticize them for their treatment of users kept me away. Whatever. Now Mplayer has a pre1 version of release 1.0 out there and it's time for another look." Newsforge and Slashdot are both part of OSDN.
any particular reason I would use this? As far as I can tell, Windows Media Player 9.0 seems to do everything I need.
hope you can hear this ok
The OSX build of MPlayer is very useful, it's the best DivX player for OSX! Of course it plays other formats as well. Thanks MPlayer team!
---
I support spreading santorum
I claim this FP in the name of RICE !
I've used mplayer on and off for a while now, and it is the preferred media player in linux for me... are there any other alternatives out there that are as easy to use and accept as many file types?
Try Xine! I like it alot!
I'm not addicted to cocain, I just like the smell of it...
Xine works as well, accepts Windows Codecs, and is as easy to use. The front-end sucks ass tho, so get your keybindings set.
I'm in 2 minds. Using mplayer for me is very settle-for-almost-working. It's painful in part, it's frustrating, it does MOST of what I want while always having something missing that I need, yet it's still the best out there.
And getting abuse from developers when I dare ask for fixes is tiring, people. I'm no coder, I just want to watch video in Linux
Sure, it's great to have a v1.0 release of MPlayer, but on the other end of the stick, Xine is not far off from hitting the 1.0 status as well. Won't this seem daunting to the end user (labelled automatically as stupid), having two different applications, with individual libraries, for doing the exact same thing. :P
Perhaps some collaboration between MPlayer and Xine should occur.
However, the fact I find most surprising, is that Microsoft hasn't stepped in argueing that the software cannot be called, "MPlayer". Perhaps it's 1.0 status may spur things on...
Let's hope the MPlayer guys don't ship their next release as version 9.0
I mean, imagine suggesting that a Linux user might not have a full and completye knowledge of the system, or that anyone should install Linux without first knowing absolutely everything about it.
Are you an idiot? The MPlayer programmers were born with this information (which does probably make them about 12, which kinda figures).
Rather than complaining you should be grateful and worshipful that they deigned to come down to this level, and allow us mere mortals access to their holy media player.
ISP or is newsforge.net already down? Could someone do some karmawhoring or mirror, google doesn't have a cache of this document yet it seems.. :(
-rzei
Mplayer revisited
./configure make make install
./configure --enable-gui. The script ran, but it complained about not having found a Win32 codecs directory, among a long list (more than 50 items) of other things.
/usr/local/lib/codecs directory, and moved the win32codecs directory there. Then I ran the configure script again. This time there was no complaint about missing Win32 codecs.
Friday October 03, 2003 - [ 06:00 AM GMT ]
Topic - Free Software
- by Joe Barr -
It's been almost two years since I wrote about Mplayer, an open source movie player for Linux and other platforms. Rereading that story today, I see I was wrong when I predicted that Mplayer's popularity wouldn't last. It continues to rank as the most popular project on freshmeat.net. I recently downloaded pre-release 1 of Mplayer 1.0 to see how much things have changed, if at all, since then. What I found is that while some things have changed, others have not.
In December of 2001, Mplayer had the rep of playing more codecs than any other movie player for Linux. The list of codecs - both audio and video - that it supports today is quite impressive. And if you add the mplayerplug-in you can leverage Mplayer's repertoire and play the most popular video formats used online in Mozilla, Galeon, Netscape, and maybe Opera, too.
Mplayer also had the rep of being a tough install and of being even tougher on users - noobs or not - who were having problems with the install. In fact, I used a comment from a frustrated user posting on freshmeat.net for the title of my first article and called it "Mplayer: the project from hell." Let's start with the install issue first and save the other for last.
Buried deep in the Mplayer documentation - in the section on installation - are a few lines of text that make the process seem completely trivial. They read as follows:
Features:
* Decide if you need GUI. If you do, see the GUI section before compiling.
* If you want to install MEncoder (our great all-purpose encoder), see the MEncoder section.
* If you have a V4L compatible TV tuner card, and wish to watch/grab and encode movies with MPlayer, read the TV input section.
* There is a neat OSD Menu support ready to be used. Check the OSD Menu section.
Then build MPlayer:
At this point, MPlayer is ready to use. The $PREFIX/etc/mplayer/codecs.conf file is needed only when you want to change its properties, as the main binary contains an internal copy of it.
Actually, there is a little more to it than that. And a lot of reading in those docs is highly recommended before you begin. Here's how I installed Mplayer from the pre-1 1.0 source code on Red Hat 9.0 running Ximian Desktop 2.
I began by going through the list of requirements and making sure that I had not just each app noted, but an acceptable release of each. Except for gcc, that is. I ignored the rants and held steady with gcc-3.2.2-5 shipped by Red Hat.
Then I was ready to download: I grabbed mplayer-1.0pre1 and the codecs I thought I needed plus a skin or two from the downloads page on the Mplayer site. I created an mplayer directory in my home directory, then used bunzip2 to decompress each of the downloads and then ran tar, which unpacked them and stowed them away in their own directories. For neatness, I created a separate tar directory and moved the tar files themselves there afterwards.
Then I entered the mplayer-1.0pre1 subdirectory tar had created and ran the configure script with the gui option:
I had downloaded the Win32 codecs, but they were needed in a directory I didn't have. No problem. I changed to su, created a
Then I went through the configure.log and checked every one of the 50 items it had noted as deficient or missing. None of them were critical. Many didn't even apply to me as they were for different platforms completely. So I started make and took a break.
I came back about 15 minutes later and fo
http://www.hadess.net/totem.php3
MPlayer 0.92 is the current stable release where everything works as expected.
MPlayer 1.0-pre1 has some nice new stuff, but even though it has one thing (support for input from v4l devices with hardware MJPEG support) which I've wanted ofr a long time, the current pre-release is much too flakey for me to use, and I've gone back to 0.92.
MPlayer 1.0-pre1 is for writing bug-reports, not reviews.
Unless Mr. Barr had a conscious or subconscious WISH to find things that didn't work right, i don't see why he wrote his review for the pre1 version.
OSDN has slashdotted itself,wtg!
"Comedy's a dead art form. Now tragedy, that's funny."
I used it as DJ in my nightclub.
All the men want to be him. And all the ladies wan't to be with him.
- by Joe Barr -
./configure make make install
./configure --enable-gui. The script ran, but it complained about not having found a Win32 codecs directory, among a long list (more than 50 items) of other things.
/usr/local/lib/codecs directory, and moved the win32codecs directory there. Then I ran the configure script again. This time there was no complaint about missing Win32 codecs.
It's been almost two years since I wrote about Mplayer, an open source movie player for Linux and other platforms. Rereading that story today, I see I was wrong when I predicted that Mplayer's popularity wouldn't last. It continues to rank as the most popular project on freshmeat.net. I recently downloaded pre-release 1 of Mplayer 1.0 to see how much things have changed, if at all, since then. What I found is that while some things have changed, others have not.
In December of 2001, Mplayer had the rep of playing more codecs than any other movie player for Linux. The list of codecs - both audio and video - that it supports today is quite impressive. And if you add the mplayerplug-in you can leverage Mplayer's repertoire and play the most popular video formats used online in Mozilla, Galeon, Netscape, and maybe Opera, too.
Mplayer also had the rep of being a tough install and of being even tougher on users - noobs or not - who were having problems with the install. In fact, I used a comment from a frustrated user posting on freshmeat.net for the title of my first article and called it "Mplayer: the project from hell." Let's start with the install issue first and save the other for last.
Buried deep in the Mplayer documentation - in the section on installation - are a few lines of text that make the process seem completely trivial. They read as follows:
Features:
* Decide if you need GUI. If you do, see the GUI section before compiling.
* If you want to install MEncoder (our great all-purpose encoder), see the MEncoder section.
* If you have a V4L compatible TV tuner card, and wish to watch/grab and encode movies with MPlayer, read the TV input section.
* There is a neat OSD Menu support ready to be used. Check the OSD Menu section.
Then build MPlayer:
At this point, MPlayer is ready to use. The $PREFIX/etc/mplayer/codecs.conf file is needed only when you want to change its properties, as the main binary contains an internal copy of it.
Actually, there is a little more to it than that. And a lot of reading in those docs is highly recommended before you begin. Here's how I installed Mplayer from the pre-1 1.0 source code on Red Hat 9.0 running Ximian Desktop 2.
I began by going through the list of requirements and making sure that I had not just each app noted, but an acceptable release of each. Except for gcc, that is. I ignored the rants and held steady with gcc-3.2.2-5 shipped by Red Hat.
Then I was ready to download: I grabbed mplayer-1.0pre1 and the codecs I thought I needed plus a skin or two from the downloads page on the Mplayer site. I created an mplayer directory in my home directory, then used bunzip2 to decompress each of the downloads and then ran tar, which unpacked them and stowed them away in their own directories. For neatness, I created a separate tar directory and moved the tar files themselves there afterwards.
Then I entered the mplayer-1.0pre1 subdirectory tar had created and ran the configure script with the gui option:
I had downloaded the Win32 codecs, but they were needed in a directory I didn't have. No problem. I changed to su, created a
Then I went through the configure.log and checked every one of the 50 items it had noted as deficient or missing. None of them were critical. Many didn't even apply to me as they were for different platforms completely. So I started make and took a break.
I came back about 15 minutes later and found make had completed successfully. I ran make install as root, then exited to
Sigs are awesome huh?
MPlayer has matured, both in code and attitude over the last year or so, or at least I've found it to be true. I never really had trouble installing it in the first place (all you had to do was *gasp* read the directions and follow them), but the install has gotten easier. I find that it also works better on my PC now. Additionally, their teams seems to had lost a bit of the attitude-- a quick glance over the docs doesn't reveal any references to how stupid the average mplayer user is :). Maybe they finally realized that attitude was offending some people,and hurting the project, so they got over themselves.
====
Crudely Drawn Games
I've managed to compile and successfully run GNUMach and GNU/Hurd from CVS. I know my way around building code. But mplayer is still a pain in the ass. Seriously. And when I read the forums, I didn't dare ask a question. The developers' attitudes represent one of the most valid criticisms of the Free Software world -- support is fleeting.
As for using the software, it works pretty well, and has steadily improved. But I don't build it anymore -- I use the unofficial debian packages, and they work pretty much flawlessly.
morons write: "It's been awhile since we first wrote about planet/population rescue initiative (formerly unknown as the oil for babies program). Maybe the fury of the corepirate nazis reaction to the fact that we dared to criticize them for their treatment of the population/planet increased yOUR determination. Whatever. Now the planet/population rescue initiative has a rather large/growing following.
morons, & the planet/population rescue initiative, are both parts of the creator's newclear power plan.
consult with/trust in yOUR creator. that's the spirit, moving you.
best to you pappa joe.
Doesn't the author understand how the Linux/OSS community works, or what? Its not the devs' job to make shiny installation druids that you can click through. That's what distros are for. If you want to compile software, be prepared to do your homework. If not wait for the
Gimme a break.
I use Xine you insensitive clod!
Repeat after me.. s.. p.. e.. E
VLC from VideoLAN accepts almost all the formats MPlayer groks. The major exceptions are the ones for which there is no GPL-compatible implementation. It can also transcode streams into different formats, or send them to the network, serve them as HTTP, etc. It is truly cross-platform and the Windows and OS X ports are extremely popular.
God, root, what is difference ?
You should know how to spell "cocaine" before you start smelling it, retard.
Anyone who would criticize an open source tool is a dumbass. The authors have worked hard to create a free tool the community can use. If you don't like it, find something else or write a replacement...but don't be an idiot and put down someone else's hard work.
Windows install:
./configure make make install
./configure --enable-gui. The script ran, but it complained about not having found a Win32 codecs directory, among a long list (more than 50 items) of other things.
/usr/local/lib/codecs directory, and moved the win32codecs directory there. Then I ran the configure script again. This time there was no complaint about missing Win32 codecs.
run setup.exe
Linux install:
"Buried deep in the Mplayer documentation - in the section on installation - are a few lines of text that make the process seem completely trivial. They read as follows:
Features:
* Decide if you need GUI. If you do, see the GUI section before compiling.
* If you want to install MEncoder (our great all-purpose encoder), see the MEncoder section.
* If you have a V4L compatible TV tuner card, and wish to watch/grab and encode movies with MPlayer, read the TV input section.
* There is a neat OSD Menu support ready to be used. Check the OSD Menu section.
Then build MPlayer:
At this point, MPlayer is ready to use. The $PREFIX/etc/mplayer/codecs.conf file is needed only when you want to change its properties, as the main binary contains an internal copy of it.
Actually, there is a little more to it than that.... I created an mplayer directory in my home directory, then used bunzip2 to decompress each of the downloads and then ran tar, which unpacked them and stowed them away in their own directories. For neatness, I created a separate tar directory and moved the tar files themselves there afterwards.
Then I entered the mplayer-1.0pre1 subdirectory tar had created and ran the configure script with the gui option:
I had downloaded the Win32 codecs, but they were needed in a directory I didn't have. No problem. I changed to su, created a
Then I went through the configure.log and checked every one of the 50 items it had noted as deficient or missing. None of them were critical. Many didn't even apply to me as they were for different platforms completely. So I started make and took a break. " etc etc etc ad nauseum.
am I the only one who read pre1 as perl spelled rather poorly?
md5sum
d41d8cd98f00b204e9800998ecf8427e
Make me momma joe? Please?
Mplayer revisited
./configure make make install
./configure --enable-gui. The script ran, but it complained about not having found a Win32 codecs directory, among a long list (more than 50 items) of other things.
/usr/local/lib/codecs directory, and moved the win32codecs directory there. Then I ran the configure script again. This time there was no complaint about missing Win32 codecs.
Friday October 03, 2003 - [ 06:00 AM GMT ]
Topic - Free Software
- by Joe Barr -
It's been almost two years since I wrote about Mplayer, an open source movie player for Linux and other platforms. Rereading that story today, I see I was wrong when I predicted that Mplayer's popularity wouldn't last. It continues to rank as the most popular project on freshmeat.net. I recently downloaded pre-release 1 of Mplayer 1.0 to see how much things have changed, if at all, since then. What I found is that while some things have changed, others have not.
In December of 2001, Mplayer had the rep of playing more codecs than any other movie player for Linux. The list of codecs - both audio and video - that it supports today is quite impressive. And if you add the mplayerplug-in you can leverage Mplayer's repertoire and play the most popular video formats used online in Mozilla, Galeon, Netscape, and maybe Opera, too.
Mplayer also had the rep of being a tough install and of being even tougher on users - noobs or not - who were having problems with the install. In fact, I used a comment from a frustrated user posting on freshmeat.net for the title of my first article and called it "Mplayer: the project from hell." Let's start with the install issue first and save the other for last.
Buried deep in the Mplayer documentation - in the section on installation - are a few lines of text that make the process seem completely trivial. They read as follows:
Features:
* Decide if you need GUI. If you do, see the GUI section before compiling.
* If you want to install MEncoder (our great all-purpose encoder), see the MEncoder section.
* If you have a V4L compatible TV tuner card, and wish to watch/grab and encode movies with MPlayer, read the TV input section.
* There is a neat OSD Menu support ready to be used. Check the OSD Menu section.
Then build MPlayer:
At this point, MPlayer is ready to use. The $PREFIX/etc/mplayer/codecs.conf file is needed only when you want to change its properties, as the main binary contains an internal copy of it.
Actually, there is a little more to it than that. And a lot of reading in those docs is highly recommended before you begin. Here's how I installed Mplayer from the pre-1 1.0 source code on Red Hat 9.0 running Ximian Desktop 2.
I began by going through the list of requirements and making sure that I had not just each app noted, but an acceptable release of each. Except for gcc, that is. I ignored the rants and held steady with gcc-3.2.2-5 shipped by Red Hat.
Then I was ready to download: I grabbed mplayer-1.0pre1 and the codecs I thought I needed plus a skin or two from the downloads page on the Mplayer site. I created an mplayer directory in my home directory, then used bunzip2 to decompress each of the downloads and then ran tar, which unpacked them and stowed them away in their own directories. For neatness, I created a separate tar directory and moved the tar files themselves there afterwards.
Then I entered the mplayer-1.0pre1 subdirectory tar had created and ran the configure script with the gui option:
I had downloaded the Win32 codecs, but they were needed in a directory I didn't have. No problem. I changed to su, created a
Then I went through the configure.log and checked every one of the 50 items it had noted as deficient or missing. None of them were critical. Many didn't even apply to me as they were for different platforms completely. So I started make and took a break.
I came b
For those of us who are less than happy about MPlayer's default GUI, there are far better alternatives, like KPlayer for KDE.
This guy's article is self congratulatory and self seeking. I don't care what run-ins he's had with the developers in the past.
A terrible review where he actually admits to not really checking it out fully, but still manages to come to the self-affirming conclusion that he was right all along, and takes the opportunity to take a personal jab at the project.
The only thing I learnt from this article is that the writer is bitter, and lacks tact.
Firstly, this uses Win32 Codecs. Most of the ones I've seen have a clear EULA that forbids use on other operating systems. Secondly, it supports MPEG playback. MPEG is a patented algorithm. They do not have a licence. Thirdly, it was created by reverse engineering. Clearly this is an EULA violation.
Their responses to criticisms suggests are very similar to street trader's responses when you suggest that their good may be stolen. Rather than being congratulated, these people shopuld be taken away and locked up.
Comment removed based on user account deletion
The problem I heard about MPlayer was that it illegaly contained DivX code that was under a proprietary license.
Last time I checked was two months ago and MPlayer was still in violation of DivX copyrights. No distro can distribute it as the developer releases it. This is the real problem. This pushes it from Free Software to "cracked warez".
(SuSE, and maybe others, do distribute it but they rip out the illegal code, so it's missing a few codecs. Debian will also be shipping a stripped, legal version soon.)
Ciaran O'Riordan
Expert in software patents or patent law? Contribute to the ESP wiki!
If you're a fan of mplayer, you might want to check out MoviX which makes bootable mplayer distributions. My favorite variation is MoviX^2. You boot from the movix2 CD, eject the movix2 CD, pop in a CD or DVD with any mplayer supported format, and there you go!
--- Often in error; never in doubt!
I don't understand the people that love xine. It has one of the worst interfaces under the sun. Sure it looks cool, but horribly unfunctional. MPlayers interface actually *works*. Even when using the Xine skin.
maybe its better to pitch in and help write the documentation for the project than to lambaste the devs for poor documentation. Regardless, its available precompiled on nearly any distro. Worked fine on Slackware 9.1 by going to linuxpackages.net (the home of all slack packages) downloading, and rning instllpkg mplayerx...
Did anyone else ever notice the "UNUSABLE FOR WINDOWS!" message next to the win32codecs in the downloads section? That seems to imply mplayer actually has a windows version, probably confusing for some people.
WOO HOO for mPlayer. I remember back in the day trying to get that mutha to compile. It was a pain in the neck. But once i did it, i had VIDEO ON LINUX!!! WOW. Now it is used all over as underpinnings for other apps. Its projects like these that are so great. This is where i feel opensource shines. Instead of doing a lot of work yourself, take a project that is established and working, and extend it. Xbox media player and now Xbox media Center both use mPlayer. By using the source that was available to them, it increased time to live so to speak. It works great and supports TONS of formats. Why reinvent the wheel. Especially in video players and html renderers (KHTML, MOZ).......
You'd think that after 10 years he would know that movie players doesn't play codec, they play movies...
Quote: And:Sure hasn't. Joe Barr is obviously still incapable of reading documentation...
My prediction: He'll be back in another two years to prove once again he's still not capable of understanding simple instructions...
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
mplayer is awesome. It plays anything and everything. I would love nothing more than to have a version of mplayer for windows. I've heard of people running it under cygwin, but I haven't been able to make it compile. I got it under gentoo, and it rules. Go mplayer go!
The GeekNights podcast is going strong. Listen!
If you want to compile software, be prepared to do your homework.
What homework?
emerge mplayer
??
Funnily enough I installed 1.0prewhatever last night.
./configure
I downloaded the source, typed
make
su -c "make install"
And I was done.
(I didn't bother downloading any skins or anything posh like that. CLIs are good enough for the likes of me.)
Mind you, that was on Slackware 9. But even so, I think yon reviewer may be taking the piss a bit. Why did he expect a CVS build to work as cleanly as an official one. Isn't the point of a CVS version being available so people can see and help with a work in progress>
-- Proud descendant of semi-nomadic cattle-herders.
Gentoo makes the installation completely painless, although configuration can sometimes be a pain in the ass. I'm happier editing config files than dealing with make, though.
With all the complains about the GUI setup, you'd think there'd be more people using the completely painless command line version:
mplayer
(file magically works perfectly)
I watch my videos in fullscreen anyway, so GUIs just get in the way. The only thing they seem to add is random seek, which is a useful feature, but not what people seem to be complaining about.
Visit the
Forgot the "and then I copied the codecs into the appropriate directory" stage, but that wasn't exactly rocket science.
-- Proud descendant of semi-nomadic cattle-herders.
YOU FAIL IT!
Why did they pointlessly violate the established (and useful) double-dash for long options convention in favour of an ugly and irregular one dash for all options? I'm aware that it's probably an imitation of the X standard, but in this day and age that's probably not a good thing to imitate. Also, it doesn't allow you to abbreviate with one-character options.
You look beautiful! Incidentally, my favourite artist is Picasso.
I'm starting a project on source forge, and can use all the help I can get.. It's called "amount of time it takes for half of a radioactive substances atoms to decay 2"
We've already got a lot of good source code up but we can use some help... especially with artwork as we have none except some scattered images we found, er, created.
Look us up on http://www.sourceforge.net.
Thanks in advance.
The AOTITFHOARSATD 2 Team.
For a good time call www.sawkie.com
It seems that a lot of the innovative "best of breed" open source projects are run by utter assholes: Mplayer, Qmail, OpenBSD, etc.
I suspect that it's not coincidence. Building concensus and playing well with others means making compromises. Compromises are the enemy of innovation. It's the people who take their ball and go home who crack the mold. They go off in "unprofitable" directions. Most of them labor in obscurity. A few of them turn out to be right and manage to produce something useful.
Forward, retransmit, or republish anything I say here. Just don't misquote me.
"... I made the Mplayer binary SUID and that helped. ..." /proc filesystem. Use this command to enable RTC for normal users:
/proc/sys/dev/rtc/max-user-freq
i dunno why he would do that but if it is about RTC then a closer look to mplayer (excelent) documentation would show this:
If you are running kernel 2.4.19pre8 or later you can adjust the maximum RTC frequency for normal users through the
echo 1024 >
Smile... tomorrow will be worse.
Bwaahaahaa. MPlayer trolls, now I've seen everything.
Did you download the binary version for Mac OS X? It's available here: http://mplayerosx.sourceforge.net/
I coudn't find information about it now, but it probably requires OS X 10.2.
I love this program, but I also use VLC, which you can get from videolan.org. Most videos look better in mplayer, but some (esp. with 2 audio tracks, i.e. two languages) play only in VLC.
I hope I could help you...?
I don't need a signature.
Maybe because that's supposed to be the closest thing to what the official 1.0 release will be? You know, the thing that's for real users, not developers, hackers, experimenters, and folks with way too much time on their hands? People who just want to see a video, not solve open source puzzles?
bubba is waiting for you!
Oddly enough I've never tried compiling GnuMACh, but mplayer compiles these days with a straight ./configure; gmake; su -;gmake install
The tricky part seems to be to ensure you have the codecs mplayer needs, and have them in a palce where mplayer can find them (/usr/lib/win32) Oh, and you need to have a version of gcc that is know to work with mplayer.
The Mplayer project's distribution of copyrighted win32 codecs is illegal.
One needs explicit permission from the copyright holder to distribute copyrighted works.
The Mplayer project does not have such permission from Apple, Microsoft and Real.
The codecs are available for free (as in beer) from their respective owners, but the included EULAs do not grant permission to redistribute.
It is obvious why Mplayer has yet to be accepted by Debian. The Mplayer team has no respect for copyright law and continues to violate the law.
I crave a simple gui. The skins for mplayer suck.
i want 1 window. 1. Does any one remember the zen of windows media player 7? 1 window, with unobtrusive and simple controls. No nasty borders, no ugly hard to use skins, no craptacular multiple window where is the widget to make it stop hunting garbage; no how the fuck to i open another file from here? confusion.
Sigh.
-T
Old truckers never die, they just get a new peterbilt
Won't this seem daunting to the end user (labelled automatically as stupid), having two different applications, with individual libraries, for doing the exact same thing.
No. Xine should be installed on systems intended for non-techie end users. Mplayer is not a particularly great choice for non-techies. A'rpi is very much opposed to the idea of binary distributions (since it means that things may run slightly slower on a given system), and Mplayer can support so many things that to set up everything required for full support during a build can take a long time. It's less bad than building GNOME or KDE, but it's definitely not an "rpm -Uvh" either.
That being said, I use mplayer exclusively, and love it to death. It's keyboard controllable, can be used without one of those godawful "fake media player" UIs, is faster than anything else in existence, and has support for just about every interface and codec under the sun (that Open Source folks can get their hands on or reverse engineer). Those of you not familiar with Barr and A'rpi (the lead mplayer developer for a long time) should be aware that the two intensely dislike each other, and have flamed each other for ages. Regardless of how good Barr is in most areas (and this review seems pretty reasonable, saying that "mplayer ain't a great choice for Linux newbies", which is definitely true), keep in mind that he's quite likely to have some bias, as A'rpi does when talking about Barr on the mplayer website. I take both with a big, big grain of salt.
Perhaps some collaboration between MPlayer and Xine should occur.
It does. Of course, it's full of people flaming each other for not giving sufficient credit, but the two projects have shared a *ton* of code in the past, and is the only reason either of them are as good as they are.
May we never see th
emerge mplayer. Done =]
That's all it takes. I installed yum from FreshRPMs, and no configuration was required.
If you issue the following two commands:
then any software you have installed will be kept up-to-date automatically, every night. It doesn't have to be hard to use Linux. Why do people insist on making it appear harder than it is? To frighten noobies?
Can You Say Linux? I Knew That You Could.
Come on, don't write something like this... please! If you have nothing constructive to say, shut up.
To be listened by several brings you responsabilities.
This build does not contain all available options in mplayer. There's no mga or xmga support (which I use), for instance. If you want the goodies, you have to do the build yourself.
May we never see th
If it infringes a patent that is not licensed for zero-cost use, it cannot be distributed under the GPL.
GPL, section 7:
"If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all."
I asked a question and gave the basis for my question. The ffmpeg library does infringe a patent. The patent has not been enforced for decoding before, but that doesn't mean it will not be enforced in the future (say, when an IP firm buys the patent), and it has been enforced for encoding, so a programmer that receives this code cannot do what she likes with it.
Expert in software patents or patent law? Contribute to the ESP wiki!
I prefer the idea of gstreamer ... ;-). ... when I tried gstreamer and mplayer last month (on RedHat 9) mplayer worked much better. For example, gstreamer claimed to play Quicktime but didn't. I know I was in trouble when gst-launch-ext (sp?) -- the script that plays files based on their extensions -- said .mov was invalid!
you define a graph to play your content. You can even describe the graph on the command line
mplayer uses Windows DLLs - yuck.
Just one problem
Do not run SUID root if there is any other way to get the desired performance. From: http://www.securityfocus.com/archive/1/339193 Severity: HIGH (if playing ASX streaming content) LOW (if playing only normal files) Description: A remotely exploitable buffer overflow vulnerability was found in MPlayer. A malicious host can craft a harmful ASX header, and trick MPlayer into executing arbitrary code upon parsing that header. MPlayer versions affected: MPlayer 0.90pre series MPlayer 0.90rc series MPlayer 0.90 MPlayer 0.91 MPlayer 1.0pre1 MPlayer versions unaffected: MPlayer releases before 0.90pre1 MPlayer 0.92 MPlayer HEAD CVS Notification status: Developers were notified on 2003.09.24 Fix was commited into HEAD CVS at 2003.09.25 02:36:36 CEST MPlayer 0.92 (vuln-fix-only release) was released on 2003.09.25 12:00:00 CEST Patch availability: A patch is available for all vulnerable versions. Suggested upgrading methods: MPlayer 1.0pre1 users should upgrade to latest CVS MPlayer 0.91 (and below) users should upgrade to 0.92 OR latest CVS MPlayer 0.92 is available for download. -- Gabucino MPlayer Core Team
Difficult installation? cd /usr/ports/multimedia/mplayer && make install clean and you're done. What's so hard about that? </gloat>
Sadly both xine and mplayer have horrible GUIs by default. Totem on the other hand, which uses the xine libs for it's video playback, has a nice clean GUI that is actually usable. Personally I use mplayer from the command line out of habit, but the lack of a gui that doesn't suck would be a nice option.... I think even jwz ranted about this some time back /me puts on mod-proof undies
What's the best way to watch DVDs? Do any distros even support this out of the box? Presumably they would have ship with DeCSS. I tried to get playback working under Mandrake 9.1 the other day, and after several frustrating hours I ended up with something that couldn't even match Windows 4 years ago. It requires adding in the PLF sources, but the latest version of the Xine player didn't seem to have all the packages available; VLC worked, but kept dying silently (core dump?); MPlayer seemed to require too much command line, and didn't seem to support DVD Menus anyway. I didn't get as far as trying Ogle (or whatever it's called) as I was too annoyed by then.
Oh what's going on with Livid? Their web page doesn't seem to have seen much activity in a couple of years. And finally, I was thinking of dumping Mandrake and switching to Debian Unstable on my desktop... anybody know how things like MPlayer square up there?
Maybe you're thinking of funk or something. Techno just goes boom boom boom boom.
For Mandrake 9.1, it was a simple matter of "urpmi mplayer" to get the basic MPlayer installed. Finding the Windows DLLs so MPlayer could play Sorenson QuickTime files (and presumably others) was harder, but doable through Google. Installing them so MPlayer could use them was reasonably easy (create /usr/lib/win32 and copy the DLLs there), though adding an import function to the GUI that would automatically extract and copy the files would have been better for the less technical users .
For those of us who got tired of doing so many source installs which required fighting with the install process, waiting for your distributor to do the integration work for you makes even something as notoriously difficult to install as MPlayer nearly painless.
For cheezor's sake, why?
That would bend the RPMs over and force them to take it anally. I mean, serriously. I can't imagine the extent that RPM HELL would be enflamed by that.
Get over it, use Debian, eh?!
[ReidNews]
want a dvd? You need to use the "dvd" URL
dvd://title#
But this syntax
dvd://title#/chapter#
Doesn't work, you need this:
dvd://title# -chapter chapter#
Which is more typing than: -dvd title# -chapter chapter#
And filters for -vop are applied IN REVERSE ORDER.
How about this malarky:
-vop detc=dr=1:ar=0,denoise3d
commas distribute over colon, colon over equals, except for the first equals that shows a filter has options.
urrggghh...
Oh, and the syntax is horrible just in general. Some options only take effect when they come before or after certain things, certain ones depend on other options in weird ways (video filters, codecs, and -fps/-ofps hell).
Still, I love mplayer. Who am I kidding. I just way too much time trying to figure out how to do things I KNOW should work, I just can't get a handle on it.
ecasound, while having also having an insanely rich command line, is more logical.
Fuck Beta. Fuck Dice
On OS X MPlayer is about the only media player that will balls-out play just anything. Bottom line, this is what it's all about. That's the killer-app of video as far as I'm concerned. The program that does not make it the user's concern what format, what encoding method, or who copyrighted what. Don't hassle me with technical crap. When I want that, I'll open a term window. But when I'm going throug video clips, I certainly don't need that kind of hassle. (often, my right hand is covered with lotion at this point :)
However, there are a couple of clips I've tried playing that'll hang MPlayer in a very ugly way, often taking Finder with it, occasionally taking the whole system along for the ride. (especially if that clip was on a CD). Granted, these files are almost certainly corrupted in some way. And every one of them that hangs MPlayer won't even open for other media players (quicktime, WiMP, VideoLan).
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
emerge mplayer Wow. that was tough. I think I need a beer and a pizza to help recuperate after such a trying ordeal.
The only reason I keep my Windows partition is so I can mount it like the bitch that it is.
You only need a few things. MPlayer source. Win32 libs. Put win32 libs in /usr/lib/win32, extract MPlayer source, ./configure && make && make install. There are a couple extra libs you can compile mplayer against but they aren't necessary.
It had some problems on old systems, pre gcc-2.95.3, other than that I have never seen any problems getting it up and running on any distro on any hardware.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
What's the matter Debian troll? Scared because the only reason to use Debian is now available on the better linux distro?
Pfft. Get a life dickwad nobody cares about your lame distro. You and the other 3 people who use Debian can go have a circle jerk now.
End-users shouldn't have to compile mplayer. That's what we have Linux distributions for. They package things so that software that can be installed with a single command (three commands if you are not set up for it):Mplayer necessarily has lots of dependencies, and you can't blame its developers for that.
Of course, mplayer doesn't just ship with many Linux distributions out of the box in the first place (or is crippled) probably because of software patents and DCMA concerns. So, blame that this is even an issue on the USPTO and RIAA.
Universal Health Care == TIA
Think about it.
My biggest pet peeve about MPlayer is the fact that it lets audio and video go out of sync, and then proceeds to complain that the machine is too slow, when I know many times that such is not true. Synching audio and video under Linux is not impossible because all aRTs players (Noatun, Kaboodle, etc.) do this, and they do so at full-screen, and they handle files that MPlayer complains about. aRTs may not have as much support for codecs as MPlayer does, but the ones that it can play, it plays very well, much better than MPlayer ever does.
// file: mice.h
#include "frickin_lasers.h"
urpmi mplayer mplayer-gui w32codecs
gmplayer fantastic pr0n vid
There's no way I'll try Xine ever again if that's the result!! Then again, perhaps this chipset is supported now...
-- Fuck Beta
That's because there *is* a Windows port of it, and it's located on their server. Try ftp://ftp.mplayerhq.hu/MPlayer/releases/win32-beta .
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
Comment removed based on user account deletion
Comment removed based on user account deletion
I'm the hugest linux geek there is.
I write command-line utils, no wait, CGI SCRIPTS in C.
because of this, the hodge-podge nature of the command line, and the maddening spottiness of the manpage DRIVES ME INSANE!!!! moreso than it might someone who was comfortable with a command line, and cuts and pastes from examples, maybe with a little experimentation.
But I'm a power user, and I'm grating up against it, and I don't like it.
How can I know that a script that I kick off that encodes a DVD chapter by chapter into ump-teen formats, with offsets the cut off the trailers (but of course -ss and -endpos use DIFFERENT UNITS) and subtitle redirection, and capture AC3 in one place, while stereo second langauge track goes somewhere else, and the video is noisy, so I have to apply video filtering...
Well, christ, I mean, I'll never know if it's working right until I do a few dry runs, and then sometimes I have to tweak the scripts.
With ecasound, at least I can structure my command line into sections that I can move around and comment out without so much fuss (even if I have to tweak the scripts)
My biggest gripe is how there's three different de-telecine filters, and each of them has some quirk that always fucks me up.
pullup is nice, but you can't set the output frame rate, nor use 3-pass encoding because the audio gets out of sync (you MUST encode in pass2, and you have to let it pick the output framerate)
detc never works reliably, but at least you can set the framerate.
ivtc, I have no idea what that does, but I never got it to work.
Eh, I'm done bitching.
Using it (to it's fullest extent) is hard. Building it is easy in comparison.
Fuck Beta. Fuck Dice
VLC is pretty cool, yeah. Especially if you wanna broadcast video on a LAN.
But for a media player, i found Xine to be better than both. It supports all the formats that mplayer supports, it also has a browser plugin, but it handles DVDs a lot better. In fact, the DVD menus and stuff like that works exactly as with a standalone DVD player.
Maybe he's only smelt it alittle.
What, next you're going to tell me that people are using TEN again! What's wrong with Gamespy?
Look it's a joke about my sig IN MY SIG! LOL!
advantage I have with Mplayer is actually it's keyboard interface
You can control xine-ui with keyboard shortcuts as well. Moreover, there is a text-mode interface that you can use if you don't like the GUIs.
Read the docs before making uninformed comments.
MPlayer also has the ability to specify video and sound drivers on the command line. Xine may have it
Xine does have it. It's the -V and -A switches. Please read the docs.
Xine is GUI oriented
No. Xine is a library, not a player. Whatever interface you build on top of it, it's your decision, Xine doesn't care. Indeed, the existing interfaces seem to generally be oriented towards GUI, but there is at least one text-mode interface.
The biggest plus to using mplayer [...] comes when you associate it with the file extensions
That's ridiculous. You can associate extensions with any player, and the results are similar.
Indeed, i noticed the same thing. On my system (AthlonXP/1800, GeForce2, Red Hat 9) i constantly get lower CPU usage from Xine than from mplayer, even though the mplayer documentation is so proud about their supposed "lowest" CPU usage among all players. It's actually funny...
The browser plugin included in the gxine GUI is trivial to install, just copy the right file into the Mozilla plugins directory (or your browser's plugins directory if you're not using Mozilla). No issues whatsoever, neither on my system, nor reported by other users on the mailinglist.
In short form...
Pros:
Cons:
Maybe a Pro, maybe a Con:
I find it interesting, incidentally, that MPlayer supports Ogg Theora better than XIPH does at the moment, in my opinion....(mplayer actually does play back Ogg Theora files generated by the Theora CVS quite nicely. Now if only Xiph would ever work on Ogg Theora and the Ogg specification again...)
Hacker Public Radio is our Friend
That is a known issue. SuSE ships a broken Xine package. I've seen a lot of reports on that.
Red Hat also shipped a broken version a while ago.
Don't use the version shipped by SuSE. Go to the website and download the latest release. It works without problems.
how lazy ;) I prefer to take it that little bit further when I install mplayer on gentoo and get a KDE gui on the front of it with the lengthy command:
emerge kmplayer
Warhammer forums
Open Source is for the developers. If you want developers that will do what you ask them to, go pay money to a commercial vendor.
As for getting mplayer installed, I've never found it to be anything other than trivially easy when using the FreeBSD ports collection. Then again, I found lots of things to be a huge pain in the butt on the major Linux distributions, or I never would have tried alternatives.
When I first started trying to use MPlayer I got annoyed because it wouldn't run for me.. then I actually read the directions and presto it worked. Amazing. My problem was that I hadn't bothered to find out that you need to tell MPlayer the audio and video drivers you need.
:)
Installing was never a problem for me. I've installed on several computers from source, rpm, and deb and all have went off without a hitch. Again just follow the directions and everything works. The config script located all the codecs I had installed by itself.. even some that I'd put in unlikely places.
I don't like GUI programs for watching DVD's so after a first attempt at using it (which worked) I just stopped using it. Why would you need a GUI? The whole OS is your GUI. I setup Nautilus to open movies in MPlayer and installed the plugin patch so MPlayer would work with Mozilla. That works very well for most use. When I rip a DVD I have it also build a script that tells MPlayer how to play the movie to the best of it's abilities. My ripping program then adds an option to my 'Videos' menu to make playing the movie as simple as running any other program.
I don't have a problem with speed for playback and I'm using a 933Mhz C3 CPU with no fancy video card to boost things along. If you're Athlon can't keep up I'd say you've probably selected the wrong audio/video drivers or are trying to do something fancy you need not do.
Perhaps you should wait for the stable release to do your review? Reviews on pre-releases aren't really an honest look at what a program can do. Obviously it has faults.. that is what pre-release canidates are for.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
is here: ftp://ftp.mplayerhq.hu/MPlayer/releases/win32-beta
it works perfectly for me
It should be so simple you don't NEED to read a readme to install it. It is possible, as Windows shows with it's installers. I've also seen more than one installer under Linux this simple. Devs really should strive for this. Don't make users go throug any unecessary steps or do preinstall reading. Just have them run the installer, and give them nice on screen prompts.
It may seem silly to a geek, but it makes a difference to many neophytes. They are easily scared and/or intimidated and hence each barrier, no matter how trivial, makes them more likely to fail. Try and make it as simple as possible, and it really will help Linux with the mainstream.
Thanks very much...I'm downloading it now....
-- Fuck Beta
I have been using both mplayer and xine on Gentoo [GNU/]Linux for quite some time, and I have recently become quite frustrated with mplayer. Yes, its support of many different formats is commendable, but I find it losing the synchronicity of the audio and video tracks WAY too often. I have recently brought xine from back-up to primary player, and use mplayer only when xine does not support the video file I am trying to play, which is rare. xine is fast, polished, and less buggy than mplayer in my experience. Is there any reason to bother with mplayer at all for formats that are supported by both?
As a side note, am I the only one who finds these articles to be pretty immature? This guy is just complaining left and right (especially in the first one). And inserting the piece about how playing video files in mplayer required getting video files from gnutella? Come on...
Ha ha, "get a life" from someone who flames about OS preference.
I'm a self-confessed Joe Barr apologist -- and one of those fucking red hat lusers that mistakenly tried to compile a version of mplayer as well. Boy what was I thinking?
2 7%2C128
./configure ./configure --help ./configure discovers your software and hardware environment! ... 2.96, bad
Save some of your disappointment for the mplayer developers. I found my visit to my proctologist to be more pleasant at the time than dealing with Arp'i's ego.
This is what Joe Barr ran into when he tried to coimpile mplayer circa 2001 (reposted from freshmeat).
------- http://freshmeat.net/projects/mplayer/?topic_id=1
[] Compile warning
by Christian Rose - Nov 26th 2001 14:47:10
When trying to compile MPlayer 0.50, I get:
$
You can get detailed help on configure with:
Please wait while
Detected operating system: Linux
Detected host architecture: i386
Checking version of gcc
Please downgrade(upgrade) gcc compiler to gcc-2.95.2+ or gcc-3.0+ version!
Note: gcc 2.96 is RedHat's UNOFFICIAL (it can be found only on RedHat sites, or
in RedHat-based distributions) and BUGGY gcc release. gcc 2.96 is TOTALLY
unsupported by us, because it simply SKIPS or badly compiles some MMX codes!
Important: this is NOT an MPlayer-specific problem, numerous other projects
(DRI, avifile, etc..) have problems with this shit too. DO NOT USE gcc 2.96 !!!
If you don't want to downgrade, use the --disable-gcc-checking option to avoid
this check, but DO NOT SEND BUGREPORTS OR COMPLAIN, it's *YOUR* fault!
Get ready for misterious crashes, no-picture bugs, strange noises... REALLY!
On the other hand, when I check http://www.bero.org/gcc296.html, I notice this:
asm( [...] "packuswb %%mm0, %%mm0 # B6 B4 B2 B0 | B6 B4 B2 B0\n\t"
"packuswb %%mm1, %%mm1 # R6 R4 R2 R0 | R6 R4 R2 R0\n\t"
"packuswb %%mm2, %%mm2 # G6 G4 G2 G0 | G6 G4 G2 G0\n\t"
[...]
)
While this is not exactly commonly found code, it's one of the perceived gcc 2.96 "bugs" most talked about. This code used to be in MPlayer, causing it to miscompile, and its maintainers to add loud and blatantly wrong statements to their documentation. The reason this code miscompiles (only the packuswb %%mm0, %mm0 instruction is executed) is that recent versions of gcc, starting with 2.96, support both the Intel and AT&T variants of x86 assembly.
The pipe character is an actual symbol in the Intel variant, therefore its use in asm() constructs (even comments in asm constructs) is illegal.
This has since been fixed in the MPlayer code - unfortunately its maintainers didn't remove their unjustified comments about gcc 2.96 at the same time.
Seems not very nice of the MPlayer people to provide completely unjustified loud warnings like that.
MPlayer supports my DC10+ card (as does mjpegtools of course). I'm not aware Xine does. For those who don't know, DC10+ is an MJPEG-in-hardware card with composite and SVHS ins and outs.
I love how with any story, even one NOT about debian, some stupid crotchbite fucktard debian user makes it a point to bring up debian. THIS is why people fucking hate debian users. News flash... DEBIAN IS SHIT. MOST PEOPLE HATE IT. IT SERVES NO PURPOSE. If you want easy Linux, there's mandrake. If you want commercially supported Linux, there's redhat. If you want bleeding edge high performance, there's Gentoo. If you want top of the line stability for a server, you should be using FreeBSD and no Linux at all. So debian is a USELESS distro that fills NO NICHE at all. FUCK DEBIAN.
Given that the divx algorithm is proprietary (it is, right?), how does mplayer play divx files? Does it invoke a binary supplied by divx.com, or does it include source from divx.com, or does it reverse engineer it? I ask because I'm concerned that someday soon I won't be able to play my divx files, or at least not without pay per view fees headed to divx.com...
- First they ignore you, then they laugh at you, then ???, then profit.
I'd rather it drops frames then go out of sync.
Mplayer is my favourite player hands down..Quicktime isn't even in the dock here..
... for compiling things.
If he wants the install to be easy, why not just install an rpm (he was using RH9) and be done with it?
-ss works by guessing how many frames to skip by the framerate in the header (but this can change in realtime, and often does, especially during playback if you're using pullup filters).
Meanwhile, -endpos only counts "output" time during playback or encoding.
This means segments corresponding to -ss 0 -endpos 60, -ss 60 -endpos 60, and -ss 120 -endpos 60 are not necessarily back to back 1 minute long chunks, but can arbitrarily overlap.
-ss positioning can be precise, in that you can specify a frame or byte amount to skip. Unfortunately, -endpos is always measured in units of time. This means you can never guarantee a seamless segmentation using those options unless you recode the video into a constant fps format that is de-interlaced FIRST, then segment it.
It would be nice if you could do -endpos as a "secondary" -ss where encoding when stop when a certain point in the input stream is reached. At least, using this method, the segments would be back to back, and guaranteed monotonic no matter how the parameter is used.
Perhaps call it endpos, and call the old, time-based endpos -maxtime?
Fuck Beta. Fuck Dice
Now, proving that there can be no algorithm that produces conforming bit stream sounds like a pretty challenging theoretical CS problem to me
Actually, it might be a lot harder. There exists an algorithm that produces a conforming LZW bitstream yet produces larger output than the uncompressed input. Likewise, it might be possible to make an unquantized MPEG file out of I-frames without infringing any patent, but it's not useful, given a definition of "useful" in terms of SNR for a given data rate.
However, if somebody does manage to prove that there exists a useful compressor algorithm that does not infringe the purported essential MPEG patents, Kleene's realizability interpretation along with the Curry-Howard isomorphism allow anybody with access to the proof to convert it into the algorithm.
Will I retire or break 10K?
Te posts on this thread are about OSX. Mentioning Xine does not make sense because Xine does not work under OSX. As far as I know right now there are three different types of players for OSX.
Players which use the Quick Time engine, for example cellulo.
The OSX implementation of videolan, done by the vlc developers.
The OSX port of Mplayer. It seems tht this port is not done by Mplayer developers,but by a guy from the Czech Republic.
--Did it work???
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??