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
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.
the fact I find most surprising, is that Microsoft hasn't stepped in argueing that the software cannot be called, "MPlayer"
Microsoft's product is called "Media Player". MPLAYER.EXE is merely an antiquated, conventional, DOS-format file name.
If they want their software to gain popularity and more widespread usage, they will.
"Ask not what your country can do for you." --John F. Kennedy
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 ?
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.
Tom.
Oh arse
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!
Please, pretty please, before you talk about something you know nothing about, get your facts straight.
MPlayer currently doesn't contain single line owned by DivX networks. None. Nada. (In past, they used opendivx, and while it was under opensource license, it was neither GPL compatible nor free software).
Nowadays, MPlayer uses libavcodec library from ffmpeg project. It it fully LGPL library, you can find it on sourceforge. The reason that SUSE rips it out is simple - some algorithms are patented (please note that there is a difference between owning copyright on code and owning patent on software). The patents make it impossible to ship binaries as a part of business in some contries. However, shipping source code is OK.
So, that much for your 'warez'.
well there is a windows version :)
www1.mplayerhq.hu/MPlayer/releases/win32-beta
i use mplayer under windows linux and osX
i like that you can begin to watch a movie
while your downloading it that just rocks
here we go again you can download mplayer for windows binaries2 -beta/
www1.mplayerhq.hu/MPlayer/releases/win3
and yes they do rock thats the only player im using in windows
"... 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.
Last time I checked, packaging MPlayer had major license problems. I believe at some time it was not even allowed to package according to a clause in the MPlayer license.
But even now there are problems because of all the libraries which are not in the GPL or any other Free Software license. And this is a problem mainly for Debian which has pretty rigid license terms.
Just checked and yes, there are still issues. See http://www.mplayerhq.hu/homepage/design6/news.html #debianandsusesux.
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
[ReidNews]
Two applications that do the exact same thing. Most sane people would see that as pointless and redundant. It's a waste of resources.
Never put all your eggs in one basket.
Even more funny, I did the same thing last night on a Out-Of-the-Box SuSE 8.2 System; I just had to remove the useless crippled mplayer that comes with SuSE.
/dev/dvd -> /dev/sr0 amd enable DMA access for my DVD-drive to play dvds. Ah, and I had to run it as root, and you must not forget xhost + then to allow it to open a window. And Mplayer is the most blithering piece of software I know, but I found these messages were generally helpful.
At first I was a bit scared by all this stuff about installing additional codecs in the documentation, and I even downloaded ffmpeg because I follwed the documentation step by step, but later I found out it applies to the cvs checkout only, is already included in the release tarballs.
The fact is: for most cases, the included ffmpeg and other included codecs will already play more stuff than any other player, and installation was as painless as you describe, I just had to add a symlink
I really love mplayer because it is fast and responsive, delivers a much better quality than any windows player I used, has the freedom to jump ten seconds with arrow keys, ignories dvd no-skip zones, allows to adjust audio/video sync, to easyly correct aspect ratio, to adjust pan-scan (E/W key) and has really good deinterlacing for my kite surfing dvds.
If there is a piece of software that make me feel liberated, it is mplayer; it is the most single reason for me to boot linux as there is nothing comparable for windows. (Yesterday I found out mplayer runs under cygwin, but I didnt try yet)
p.
Without order, nothing can exist. Without chaos, nothing can be created.
it doesn't seem to support all the same formats that mplayer does [...] Xine doesn't play .asf files
If you install the Win32 codecs, Xine will happily play all those formats you mention.
I've a few mpg's that mysteriously don't play on xine
I've a few mpg's that not misteriously don't play but on one of the players that i use (xine, VLC, mplayer...) and on none of the other. The "mplayer plays all files that other players won't play" myth is just that: a myth. You will always find files that are not playable on all players (or even worse, are playable on only one player).
mplayer renders much more sharply and clearly than xine
You are probably not using the Xv mode in Xine. If you use XShm (compatible with almost any hardware, but slower) the image is kinda blocky indeed. But any player (not just Xine or mplayer) that uses the Xv mode has the same sharpness. I actually spent some time figuring out this issue and i'm pretty sure about what i said above.
Like i said, both players (Xine and mplayer) are pretty much the same, except that Xine handles DVDs a lot better (mplayer's implementation is only the bare minimum).
Ask a specific question. If you say "Can someone help me to get X working...", you're going to get a "no". Why? Think of what you actually just asked -- you, one of zillions of people, just said "will you commit an unknown amount of time to providing me with support for free".
While you did an excellent job summarizing the points, Eric S. Raymond wrote an article that I found particularly helpful, and after reading and putting into practice what he was saying (all of which made sense) i started getting a lot more help from projects, and was actually able to contribute a lot more in general. Much more satisfying, I say.
Like what I said? You might like my music
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.