Announcement

Collapse
No announcement yet.

MPlayer Is Getting Closer To Version 1.0 Too

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

  • #31
    Originally posted by deanjo View Post
    There is virtually no difference in CPU overhead during playback between XBMC and Mplayer (especially when hardware decoding is in use) and subtitles have never been an issue here with XBMC. Granted if I use sub titles they would be in English. XBMC also has a full set of picture controls as well for brightness and contrast.
    I have yet to get XBMC to play with any non-latin characters. I guess I need to get my hands on a full unicode font, as it does not do any font substitution at all.

    Comment


    • #32
      Originally posted by deanjo View Post
      There is virtually no difference in CPU overhead during playback between XBMC and Mplayer (especially when hardware decoding is in use) and subtitles have never been an issue here with XBMC. Granted if I use sub titles they would be in English. XBMC also has a full set of picture controls as well for brightness and contrast.
      It would really be interesting to figure out what you're smoking.... xbmc is a CPU HOG of the first degree. So much so that even running a hardware decoder, the crazy thing will still max out the cpu and deliver under 15 fps (on a sempron). Mplayer will run the same file at an easy 10-15% CPU while dropping NO frames.

      For reference, this is doing 1080p typical downloaded mkv files.

      Comment


      • #33
        Originally posted by droidhacker View Post
        It would really be interesting to figure out what you're smoking.... xbmc is a CPU HOG of the first degree. So much so that even running a hardware decoder, the crazy thing will still max out the cpu and deliver under 15 fps (on a sempron). Mplayer will run the same file at an easy 10-15% CPU while dropping NO frames.

        For reference, this is doing 1080p typical downloaded mkv files.
        Heh something is screwed up on your install then. It rarely goes above 5% even on highbitrate 1080p h264 here on a underclocked (800 Mhz) X2 with 0 dropped frames.

        Comment


        • #34
          I never had a single problem with mplayer. It plays everything, no gui and using the keyboard to navigate is awesomeness and simplicity with no end, and I don't think I could ask for more.

          But in those rare cases I do, like stylised subtitles or remembering where I stopped (which is no doubt configurable with vanilla mplayer, too), I use smplayer. Pity it's qt crap (one of the few good qt applications I use), otherwise the world would be perfect.

          Comment


          • #35
            Originally posted by Xipeos View Post
            Most (all?) of mplayer's encoding and muxing is handled by external libraries (lame, x264, lavc, lavf, etc.). The in-tree ffmpeg is also external (as it's pulled from its own svn and is not modified). Therefore, an encoding problem wouldn't be mencoder's fault.

            Yes it would. (be a problem with mencoder). They are the integrators of the software not me. I am the user. I use mplayer/mencoder, not ffmpeg. They use ffmpeg, wrap it with some eye candy and ship it as mplayer. If they decide to use mmfpeg tomorrow instead i would still be using mplayer and probably not notice a heck.

            If all ffmpeg was doing was saying "hello world" instead of playing movies, mplayer team would notice and act. If it has subtle bugs instead, then suddenly the responsibility shifts to the user. As if they were the more skilled in newest trends in image processing etc.

            Hah.

            Comment


            • #36
              Originally posted by RealNC View Post
              Do you? Does anyone? That means all media players are crap if their users don't run conformance tests?
              No i don't. Probably are crap, yes, more or less. The only safety net here is open source - as in "with enough eyes all bugs are shallow". The problem is that the existing OSS code base is growing fast for even the world's eyes to catch. (Not that anyone in the world would be interested in manual review of every patch to mplayer.) With this approach horrendous bugs are commonly found after circulating few years in the field. It's better than not finding them at all but it's so sub optimal.

              Comment


              • #37
                The most stable player for me has been xine with xine-ui. Mplayer was good too, but needed dvd navigation (menus etc). I don't know if this has been implemented properly in the 1.0rc's, but in the past it had issues for me.

                XBMC was good too. I really liked it, however again, dvd navigation I had issues with. I have some dvd's that won't play if dvd nav is disabled and others that won't play if dvd nav is enabled. I thought at first it might have something to do with distro's ie version/implementation of xbmc, but I have two different machines with two different distro's (kubuntu and Gentoo) with both having the same issues.

                What I'd REALLY like (being a KDE user) is a plasmoid to replace xine-ui with all xine-ui's functionality, and have the video window appear only when a stream is playing/paused... and fullscreen of course.

                Comment

                Working...
                X