Announcement

Collapse
No announcement yet.

MPlayer 1.3.0 Officially Released

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

  • MPlayer 1.3.0 Officially Released

    Phoronix: MPlayer 1.3.0 Officially Released

    MPlayer 1.3.0 was released today by the team working on this widely-used, open-source video player...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why would anyone use MPlayer when there's mpv?

    Comment


    • #3
      Originally posted by caligula View Post
      Why would anyone use MPlayer when there's mpv?
      Because it can be more customized at compile time, for example making a very lightweight player for embedded device.

      Comment


      • #4
        Originally posted by ipsirc View Post

        Because it can be more customized at compile time, for example making a very lightweight player for embedded device.
        Is this a joke? MPlayer is hugely larger than mpv.

        Comment


        • #5
          Originally posted by caligula View Post
          Why would anyone use MPlayer when there's mpv?
          I do not like mpv build system, it requires me to install plenty of python cruft I do not use anywhere else - fuck that. Furthermore, IIRC they dropped quite useful mencoder tool. Which is really badass, it breaks plenty of pre-existing automations and does NOT counts as mplayer+mencoder replacement at all.

          Sure, maybe they did it for Teh Greater Good, but it seems I do not consider it is "good" for me and would prefer to stick to "real" mplayer, not its substitutes/forks. So I would prefer to see "real" mplayer developed instead.

          Comment


          • #6
            Originally posted by caligula View Post
            Why would anyone use MPlayer when there's mpv?
            They're really fond of a frontend that only works with mplayer? That's pretty much the only valid reason I can think of.

            Originally posted by ipsirc View Post
            Because it can be more customized at compile time, for example making a very lightweight player for embedded device.
            mpv is just as customizable at compile-time as mplayer.

            Originally posted by SystemCrasher View Post
            I do not like mpv build system, it requires me to install plenty of python cruft I do not use anywhere else - fuck that.
            You have a system that's big enough to have a compiler toolchain and other stuff necessary to build various stuff, but python is where you draw the line? Seems very, very arbitrary. And I must ask, what cruft? Python itself is the only thing necessary. The waf binary, which is less than 100k in size, will be downloaded into the build directory and will not clutter the rest of the system.

            Originally posted by SystemCrasher View Post
            Furthermore, IIRC they dropped quite useful mencoder tool.
            mpv can encode: https://mpv.io/manual/master/#encoding. Yeah, you'll need to adjust your scripts, it's not a drop-in replacement for mencoder, but it's there.
            Last edited by Gusar; 20 February 2016, 09:44 AM.

            Comment


            • #7
              Originally posted by Gusar View Post

              mpv is just as customizable at compile-time as mplayer.
              Where is the alternative of config.h? I couldn't find any similar in mpv source. Help me!

              Comment


              • #8
                Originally posted by Gusar View Post
                You have a system that's big enough to have a compiler toolchain and other stuff necessary to build various stuff, but python is where you draw the line?
                Toolchain itself is needed to build virtually everything. This weird python thing is only needed by mpv, I do not need or want it for anything else. Quite a difference. And if gcc would be like python, I have to keep gcc 2.95 to build C89 progs, GCC 3.x to build C99, and brand new GCC 6.x to try brand new C++11/14 things. Fortunately gcc isn't like THIS.

                Seems very, very arbitrary. And I must ask, what cruft? Python itself is the only thing necessary. The waf binary, which is less than 100k in size, will be downloaded into the build directory and will not clutter the rest of the system.
                I'm not a windows user, so I'm not going to download binaries hell-knows-where. Packages are supposed to be tracked by package manager facility. It provides logical consistency, security updates and integrity checking. I value these patterns in Linux systems I use, so I'm going to follow and promote this way of managing operating systems. Furthermore, I really welcome "classic" configure/make approach following certain patterns regarding expected behavior and build configuration. I like these patterns, it WORKSFORME, custom build system which behave the other way are UNWELCOME. I know how to persuade configure/make based things to do what I need, it makes my life convenient. And not like if I dream to learn how to do the same in some exotic crap. Especially if it written in python, whch hints I'm going to have a lot of unpleasant experience & discoveries.

                It may or may not be autotools. Autotools are best in detecting things in various systems and verbosely tracing/logging what they do if something goes wrong, flexibly configuring flags, dirs and so on. But similar build systems are fine, as long as they manage to behave the same. Say, CMake is rather unpleasant to deal with. No obvious --help? And 3 times longer command line to get the same result? Screw that.

                mpv can encode: https://mpv.io/manual/master/#encoding. Yeah, you'll need to adjust your scripts, it's not a drop-in replacement for mencoder, but it's there.
                What is going to improve compared to my scripts whch are in place and were working? Nothing? Then it is kinda worthless job to do, fuck that. If you haven't noticed, I'm also fed up with libav thing breaking commandline & apis all the time, so I'm gone for "classic" ffmpeg. Not like if I dream to rewrite all fucking scripts or rewrite all progs around, wasting time just to get ZERO advantage over pre-existing state of things.
                Last edited by SystemCrasher; 24 February 2016, 08:20 PM.

                Comment

                Working...
                X