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.
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
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
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.
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.
Putting a blacklight in your basement and playing boom-chicka techno crap does not a nightclub make.
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.
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 ?
am I the only one who read pre1 as perl spelled rather poorly?
md5sum
d41d8cd98f00b204e9800998ecf8427e
The school or the grain? Or are you talking about adding type R stickers to things?
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).......
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.
Warning!!! Your system has been infected. Windows Media Player 9.0 is known to work only when the Microsoft Windows virus is present. As to your question, you might wish to use mplayer when you get linux reinstalled.
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.
Warning!!! Your system has been infected. Windows Media Player 9.0 is known to work only when the Microsoft Windows virus is present. As to your question, you might wish to use mplayer when you get linux reinstalled.
But I thought Linux couldn't get viruses
*rimshot*
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.
Agreed...
From the README:
And the author who refuses to read the README:
... and furthermore
"... 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.
Don't tell disco granny!
"Dumb Dumb?"
That's my club name.
Hey freaks: now you're ju
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 =]
His argument:
"I am a user savvy enough to be running linux. I am bright enough to fix problems. And yet, it was not easy for me to install this application. Therefore, it will be even harder for somebody who is new to Linux."
Your argument:
"What an idiot! He should have read the acoryphal poorly laid out document! Things are easy if you do all the chores perscribed to you by developers with no talent for technical writing and different systems than you!"
My argument:
"RTFM is not a valid complaint. Windows software installs without a manual. It does not expect you to RENAME directories after installing things to get them to work. It does not expect you to KNOW what codecs you want to use and already have them downloaded. It allows somebody to do what they need to do before hacking the source code of the underlying software. Why can't linux software do this as well. Oh right. Because we're better than them."
Hey freaks: now you're ju
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>
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.
.rm files because you don't have realplayer installed." Of course, clarifying that would weaken his point that his onging grudge war with A'rpi (ex-mplayer lead, who is equally responsible for the A'rpi-Barr flamewar).
This has a bit of Barr bias. Nothing's "wrong" -- Barr's system just doesn't have things like Realplayer installed, so mplayer is saying "I won't be able to play
May we never see th
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
It does not expect you to KNOW what codecs you want to use and already have them downloaded.
Try playing DivX when you lack support, mate. And at least with Mplayer, you'll get a vaguely helpful message -- not with Windows Media Player.
May we never see th
Yup. WMP9 is to Windows what emacs is to everything. Pretty soon, there'll be WMP mathematical simulation packages and WMP embedded systems. After all, music isn't worth listening to unless the computer has to spend clock cycles calculating colored lines to its tune.
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.
RTFM is not a valid complaint.
I'm sorry, you lost me right here. When installing code of dubious legality downloaded from Hungary with a miriad of stolen codecs and swiped protocols that is under furious development from a bunch of cankankerous weirdos, RTFM is certainly a valid complaint.
mplayer is not, and probably never be production quality software. Since (insert distro here) will never package it, it will always suck.
You don't have to RTFM for Windows, but since ther e is no TFM, or source for that matter, if things are screwed up, it's damn hard to fix it.
So my response to you: Get your grubby click and drool mits off my operating system!
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.
Windows software installs without a manual
It also isn't being installed from source, rarely has anything close to the option flexibility of source-installed software, and is usually completely useless in the event that something fails in the process. I have a copy of VS6 here that bombs near the end of the installer and there's not a damn thing I can do about it, for example. I have shit installed here that won't uninstall properly and, short of removing it manually and hunting down and undoing every little registry key and config change, there's not a damn thing I can do about it.
Why does everything have to be "the way Windows does it"? Windows sucks, that's why I use Linux and BSD. I don't WANT it to act like Windows. That's the POINT. It's NOT Windows and it WORKS, that's why I LIKE it. It's not hard to type "apt-get something". I'm sick of people apologizing for users who are too coddled and/or stupid and/or lazy to even do that - it's how you wind up with people with busted-ass systems who call you up and whine all the time that the "computer is broken". Gee - that's because you installed every damn thing you came across by double-clicking randomly...
It's okay to make things easier to a point, but you have to put some responsibility on people for what they install. Windows doesn't, and, as a result (aong with some other issues), most Windows systems out there are hideously broken beyond repair.
Besides, if you're going to immitate ease-of-use, immitate Macs, not Wintels.
We're "better than them" not because we're "1337 d00dz", but because we actually make people stop and think about what they're about to do before they do it...
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
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.
HAHAHAHAlolololololol that iz teh fnny1111!!!!!!!1111
My argument: "RTFM is not a valid complaint. Windows software installs without a manual. It does not expect you to RENAME directories after installing things to get them to work. It does not expect you to KNOW what codecs you want to use and already have them downloaded. It allows somebody to do what they need to do before hacking the source code of the underlying software. Why can't linux software do this as well. Oh right. Because we're better than them."
Have you ever tried to install a windows program that is distributed as a source package? Before switching to Linux I tried several and couldn't make a single one of them work (and I did spend some time fixing the compliation errors by reading through and correcting code).
I do not claim MPlayer is easy to build by the average user, but once you have a working configuration, it is quite easy to upgrade. Instead try to install sun-java from source, that is a project which could be much easier to build, but you never hear any complaints there.
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.
Have you ever tried to install a windows program that is distributed as a source package?
Why on earth would I want to do that? Windows' biggest success is the inclusion of everything I need to do to run a binary program already in the OS on a single (more or less) hardware architecture. There is no real advantage to compiling source rather than running a binary unless you are a developer interested in extending the application, and we developers should expect to have to jump through a few hoops. Those hoops help us acquire an understanding what's going on with a program. All they do for end users is confuse the shit out of them.
Windows has taken uniformity to a new level, and in the process has acquired a reputation for oversimplification, poor performance and general bloat. Recompiling a program that uses Windows API calls may not have much effect on performance or stability, because most applications rely heavily on calls to APIs we can't touch. Linux, on the otherhand, is at its best when used as a minimalist architecture. Everybody want to squeeze the maximum performance out of applications because they can...and that's why you felt the need to compile from source, despite there being a number of great binaries from Sun.
I've got no problem with wanting minimalism (shit, my favorite server runs a gentoo kernel with support for little else than a keyboard and an ethernet card), but when you've got a highly advanced application like a media player, I think you should really err on the side of ease of installation. I mean, reading this article...this guy performed more steps to run MPlayer than I did to BUILD my gentoo kernel...would it really kill these guys to take a few days to write an autodetecting installation that by default provided users with a 100% working beta?
Judging from what I've read about that team, probably. And that's why so much open source software is still flunking the newbie test...developers are providing what the developers want, and not what new users need, because after the community gets large enough it no longer needs to attract them. Projects get BORED of newbies and their sycophantic pleas to use their software. It's elitism, plain and simple, RTFM is developer speak for "Talk to the hand."
Hey freaks: now you're ju
That's interesting. I have installed VS6 on so many boxes so many times (as a consultant constantly switching clients and machines, that's just part of life) since 1998 that I've lost track. I have never had a single problem with it.
Your assertion that VS sucks because you don't get the code is ridiculous, since the install works 99.99% of the time for 99.99% of people who install it.
That there's a problem between the chair and the keyboard and you can't figure out how to fix whatever problem is preventing you from installing it is another matter altogether, and believe me, you don't need "the code" to fix those things.
So I'd recommend you apply this same fantastic elitist attitude to yourself and RTFM before blabbing about how "Windows sucks" because you can't figure out how to make it work.
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!
RTFM is not a valid complaint. Windows software installs without a manual
With the exception of late 80s and early 90s games that required the third word on third line of the fifth paragraph on the 13th page to install, I have NEVER seen a piece of software, open or closed source that required a manual in order to install.
There simply isnt a way to:
if Manual != Present fuxor installation else roxor
Of course, the installer has to know what to do to make the install go...
-- $G
First at all, MPlayer is easy to compile, just the usual ./configure && make & make install. I have done this from old versions (even from the 0.90pre)
Your problem is not having all the libraries installed, Mplayer comes already with a bunch of libraries bundled (libavcodec, libfaad, etc.), but mplayer cannot bundle all the windows binary codecs, imagine that!, everyone will be suing mplayer for distribuying those codecs. Then, the user legally downloads them and uses with mplayer. End of story, illegal use of codecs bypassed, everyone is happy now.
C-x C-c
Your assertion that VS sucks because you don't get the code is ridiculous,/p>
Are you an idiot? Oh wait.. that's not even in question here - you're posting anonymous coward without posting anything that would be necessary to keep your identity secret - you most obviously are either an idiot or a troll. Where did I assert that Visual Studio sucks because I don't get the code? Visual Studio sucks because it's a lousy toolset surrounding a bunch of shitty languages that are built on a half-assed API to a system that only runs right a quarter of the time.
since the install works 99.99% of the time for 99.99% of people who install it
And you got those statistics where? Your ass? The 100 homogenous machines you installed a single version of VS on? Glad to know that in your make-believe statistics I get to be the .01%.
And, I figured out how to make Windows work just fine. You use these tools called fdisk and format, then you go get a real operating system that actually runs right and install it. Like DOS.
As far as your assertion as to the problem between my keyboard and chair, I must say that the words of an anonymous coward who apparently works as a Help Desk technician - the lowest common denominator of IT jobs - installing half-assed tools on half-assed systems cut me so deeply that I simply can't express my anguish.
Give me an address and I'll mail you a quarter, kid. Come back and talk to me after you've purchased a decent system and gotten a real job.
By the way - I respond to anonymous cowards once and once only if they have no reason to post AC. Don't expect a response no matter what sort of troll you post next.
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
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.
I pissed you off, so I must be a troll. Check.
Visual Studio sucks because it's a lousy toolset surrounding a bunch of shitty languages that are built on a half-assed API to a system that only runs right a quarter of the time.
That's a great summary. I guess you use the VS equivalent in Linux... oh, wait. Never mind. And anyway, "a quarter of the time"? What was it about statistics again?
You use these tools called fdisk and format, then you go get a real operating system that actually runs right and install it. Like DOS.
HAHAHAHA!!! You kill me man. You are so '1337'. Edlin all the way, eh?
I must say that the words of an anonymous coward who apparently works as a Help Desk technician
And you got this from where? Your ass? Oh, right, if I'd logged in as "TehCodeMaster2003" you'd be all impressed, of course. You'd know exactly what I do for a living.
Don't expect a response no matter what sort of troll you post next.
Once and only once. That's impressive, eh.
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??