MPlayer Is Getting Closer To Version 1.0 Too

[renkin]

I don't know about mplayer being more stable then xine-lib or vlc In fact I've always found it to be the opposite. That is just personal experience though. I'm not a big fan of vlc either but it does seem to have more flexibility then the others. My personal preference has been actually xbmc which seems to be more stable then all the above.

I may be wrong but doesn't xbmc use mplayer as its core to play media files?

[deanjo]

If that is indeed the case then the mplayer devs are kind of dumb even using an RC label. They should have just continued on releasing a minor revision number like they did pre 1.0.

[deanjo]

I may be wrong but doesn't xbmc use mplayer as its core to play media files?

No it does not. XBMC for Xbox was a port of mplayer. The linux versions and Mac use a inhouse player called DVDPlayer and the Windows version has another player called DSPlayer.

http://en.wikipedia.org/wiki/XBMC#Video_player_cores

[phtpht]

MPlayer devs always recommend pulling from their SVN. They mentioned in the past that they consider formal releases as a way to make distros happy. They made the "rc" releases because the distros wouldn't use a recent SVN snapshot, shipping hopelessly outdated versions instead. Most distros have clueless packagers who will not pull sources from SVN even at the recommendation of the devs. So they simply pulled from SVN, named the tarball "rc" and went "here you go noob." That "rc" tarball was much better than an SVN pull because it had "rc" in its name even though it was just an SVN pull...

Go figure

This is just an excuse for lacking development process. The SVN version would be acceptable if there was some measure of its quality (ie. tests). Without that it is just an double edged sword: you're constantly using an out of date version, so any bug report requires you to update, but when you do, 20 other things break. As a result you keep updating from trunk until you're lucky enough that all the features you require actually work, then you stop caring. Now imagine yourself as the "distro noob" who actually has to deliver something that works.

[fhj52]

Who cares?
In ten years I have not seen even one mplayer that was not buggy as heck, would not play a [insert almost any container format] file without massaging the heck out it and even then it would often crash in the middle and use a configuration that is MADE to confuse the H~!~ out of otherwise intelligent people. Their website design must be at the top of the list of the worst designs ever conceived, and on and on and on ... but I cannot possibly pass up that (some of) their developers have the worst ATTITUDE of any OSS devs I have seen in over ten years which is, more or less, ''if you do not like it then F U'' ...

I don't care if it is release 10.0 ... I wasted way too many hours on the pure HYPE surrounding that god-awful media player to EVER try it again.

The only way a release of mplayer 1.0 would be part of "the year of the desktop linux" would be if they announced it would be the LAST. ...I'll take a drink on that day.


[ This has been an OPINION. It may not be yours but it is mine so no I won't get into a discussion about it. ]

[Xipeos]

(...) requires you to update, but when you do, 20 other things break. As a result you keep updating from trunk until you're lucky enough that all the features you require actually work, then you stop caring. Now imagine yourself as the "distro noob" who actually has to deliver something that works.

Your argument is complete crap in my experience. I've been using mplayer (and ffmpeg) from trunk for almost four years now. I update it every couple weeks or so, and never had a major problem (dvdread/nav stopped working at one point though). The "clueless package managers" argument also seems like nonsense (examples: 1 2 3 of packages from git/svn in two major distros).

[phtpht]

Your argument is complete crap in my experience. I've been using mplayer (and ffmpeg) from trunk for almost four years now. I update it every couple weeks or so, and never had a major problem (dvdread/nav stopped working at one point though).

Well how many of the features do you actually use and how diligent your verifications are? Do you actually check the bits in an encoded file against the appropriate standard, do you perform measurements to see if a recent update did not degrade encoding quality, or do you just go like "it still plays my favorite movies, end of testing".

[RealNC]

Well how many of the features do you actually use and how diligent your verifications are? Do you actually check the bits in an encoded file against the appropriate standard, do you perform measurements to see if a recent update did not degrade encoding quality, or do you just go like "it still plays my favorite movies, end of testing".

Do you? Does anyone? That means all media players are crap if their users don't run conformance tests?

[deanjo]

but I cannot possibly pass up that (some of) their developers have the worst ATTITUDE of any OSS devs I have seen in over ten years which is, more or less, ''if you do not like it then F U'' ...

Lol, that is one area where they are in a class of their own without a doubt.

[kiputnik]

Who cares?
In ten years I have not seen even one mplayer that was not buggy as heck, would not play a [insert almost any container format] file without massaging the heck out it and even then it would often crash in the middle and use a configuration that is MADE to confuse the H~!~ out of otherwise intelligent people.

In six years I have not seen even one mplayer that was buggy, it always plays whenever I throw at it and I don't remember it ever crashing.

Oh and, did I say that it's *the* fastest movie player out there? (Not that it matters with VDPAU, but when you're trying to play HD movie on a crappy netbook you see the difference.)

Sounds like you used it once ten years ago and now you're spreading your uninformed opinions all over the place.

As for the configuration file - does anyone even use it? I just created a wrapper script in /usr/local that calls mplayer <args I always> "$@"