Announcement

Collapse
No announcement yet.

MPlayer Is Getting Closer To Version 1.0 Too

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • phtpht
    replied
    Originally posted by Xipeos View Post
    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".

    Leave a comment:


  • Xipeos
    replied
    Originally posted by phtpht View Post
    (...) 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).

    Leave a comment:


  • fhj52
    replied
    SO?

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

    Leave a comment:


  • phtpht
    replied
    Originally posted by RealNC View Post
    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.

    Leave a comment:


  • deanjo
    replied
    Originally posted by renkin View Post
    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.

    Leave a comment:


  • deanjo
    replied
    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.

    Leave a comment:


  • renkin
    replied
    Originally posted by deanjo View Post
    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?

    Leave a comment:


  • RealNC
    replied
    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

    Leave a comment:


  • Joe Sixpack
    replied
    Originally posted by deanjo View Post
    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.
    Interesting. I' tried VLC from 0.9 to a few 1.x releases and I always ended up going to either gmplayer or smpalyer. VLC was always far less responsive when I skip around videos and it crashed considerably more. The part that pissed me off was when I rebooted and tried the same video and same VLC version in Windows it would perform 3X better. I guess YMMV.

    As far as xine... well xine just flat out stole a ton of features from MPlayer. The old maintainer used to constantly post complaints on the homepage about things xine "implemented". After he quit a few years ago (out of frustration) most of his rants were removed from the website. MPlayer always supported more formats even when using the same .dll's as xine.

    Leave a comment:


  • deanjo
    replied
    Originally posted by Joe Sixpack View Post
    That's because they're stuck in 2003 where only geeks use Linux and everyone accepted using betas and CVS as the norm. Realistically, MPlayer CVS has been faster and more stable than xine and VLC for years now. they should be at version 1.7 at the least.
    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.

    Leave a comment:

Working...
X