SMPlayer using mpv

mpv is another fork of mplayer. Many people have asked to add support for it in SMPlayer.

In this video you can see SMPlayer playing a video using mpv:

However only very basic things work (play, pause, stop, seek).

Adding full support for mpv would be very hard. The mpv developers made a lot of changes which made mpv incompatible with SMPlayer (and other mplayer front-ends).

They renamed many options, removed the slave mode, and even removed the -identify option which SMPlayer uses to get info about the video.

Actually the slave mode is not removed, but it’s deprecated and the developers said it shouldn’t be used.

Maybe it would be possible to fully support mpv, but it would be a hard work that would take months, and only if they do not actually remove the slave mode.

What do you think? Would it be worth to try to support mpv? I mean, after all probably most of the SMPlayer users wouldn’t notice any difference compared to mplayer…


10 thoughts on “SMPlayer using mpv

  1. Hi there.

    IF they (mpv devs) would have decided to keep the slave mode it would be nice to have mpv supported fully just in case of a very unlikely scenario of mplayer project going belly up. I doubt it would ever happen but life is full of surprises…

    Kind regards.


  2. I use SMPlayer on Windows. mplayer can’t play some videos (wmv for example) and eats up more CPU when using filters, so I use mplayer2 binaries instead. But mplayer2 is no longer developed, so I guess some time in the future I won’t be able to play some videos with mplayer2 too. I want to use modern software that is actively developed. mpv is the future, if SMPlayer won’t support it, I’m afraid one will think of SMPlayer as abandonware.

  3. I switched to mpv (well, a GUI using mpv) because audio passthrough and hardware acceleration on my Intel CPU worked, whereas they had issues in mplayer and smplayer. Mplayer was also having issues with some files, and then there was the whole mplayer or mplayer2 thing.

    SMPlayer was my standard video player for years though and I still like it 🙂

    As I understand it, mpv’s APIs aren’t great yet (do they even exist?) so building a GUI is complex. They also don’t seem to understand why someone would want a GUI.

    • >mpv’s APIs aren’t great yet (do they even exist?) so building a GUI is complex.

      There is libmpv, which should provide everything a GUI needs. Missing bits can be added on request. It should be much better than slave mode in general.

      >They also don’t seem to understand why someone would want a GUI.

      Sure we do. It’s just that the developers and core users don’t want/need a GUI, since command line and OSD is more than sufficient.

  4. Well I don’t think it is that important for me, since mplayer backend feels fine for me. Or mb there is any advantages of using mpv?

  5. Well, mplayer with smplayer as GUI is fantastic. I would concentrate on mplayer for short and medium time span.

    In the long run, far far in the future, it might be well considered to have mpv and smplayer as a combined best player package. Although, I would definitely rename smplayer to accomodate for the underlying change to something like smpvplayer or something.

    I wouldn’t recommend supporting mpv just yet, because the mpv development pace is to fast at the moment.
    Repository is quite active with new commits, quite a lot of version bumps,…

    Just wait for at least a 1.0 mpv release.

    Lastly, mpv already has a GUI, not so elegant and extremely pure and simple, but it has one.

    • >I wouldn’t recommend supporting mpv just yet, because the mpv development pace is to fast at the moment.

      libmpv has a stability guarantee at least for the basic things. Changes to the API are listed in DOCS/client-api-changes.rst, so it should be easy to keep up.

      Keep in mind that AFAIK smplayer parses the mplayer version number and acts upon it, because even mplayer changes behavior once in a while.

      >Lastly, mpv already has a GUI, not so elegant and extremely pure and simple, but it has one.

      No it doesn’t. It has the on screen controller (OSC), which allows the user to use the mouse for seeking and changing subtitle/audio streams. We don’t intend to add much more features to it and is not meant as a replacement for a full GUI. So there’s plenty of room left for external GUIs.

  6. I would _love_ for smplayer to support mpv. I haven’t used mplayer for years, because they just couldn’t keep up with the changes in technology and formats. Instead, I’ve used mplayer2 via smplayer2 (what finally made me switch to mplayer2 was their support of split chapters in mkv, since mplayer didn’t support them). But now that mplayer2 is essentially dead, mpv is arguably the future, but it doesn’t have any good front-ends at the moment. baka-mplayer and cmplayer are the only two that I know of, and neither is good enough to be worth using at the moment IMHO (though I wish them the best of luck). I _might_ use baka-mplayer if it let me remap the keys (which mpv-proper _does_ let you do), but it doesn’t let you do that, and it would still be painful to use it instead of smplayer, particularly since it completely lacks support for stuff like a list of recently used files. They do seem to be getting close to usable though.

    I don’t know enough about how integration with mpv would work to know how feasible it is to wrap smplayer (or something very much like it) around mpv at this point, but if it’s not feasible, then I think that the appropriate enhancement requests should be opened for the mpv devs so that they’ll add what needs adding. For now, I’ll likely continue to use smplayer2 as my main video player, because it has such a nice interface, and it’s able to play most videos properly still, but mpv definitely does better for some stuff (e.g. it handles the subtitles for the recently released Kabukimonogatari _much_ better than mplayer2 – which fails to show many of the subtitles because of how fast they change or where they’re supposed to show up), and I expect that the gap in capabilities will only grow.

    mpv _needs_ a good front-end, and since I love smplayer/smplayer2, I’d very much like to see a version of it wrapping mpv. If that can’t happen yet, then it can’t happen yet, but I think that it (or something like it) needs to happen in the relatively near future. And since mplayer and mplayer2 seem to be dead ends at this point (particularly mplayer2), I think that if smplayer wants to continue to be great in the long run, it really should have a version or a fork which supports mpv.

  7. I am trying to abstract the concept of player inside smplayer, for now it’s just a set of big ugly hack, but it can be a good starting point.
    I post the code on github, you can find mpv backend code in mpv branch :
    The master branch is the svn version.
    For now, I can load video, seek inside, change volume but I have an image ratio bug.
    A lot of work needs to be done before a stable version, a little help would be great.

  8. Support slave-mode for first step it’s ok. I don’t know what mpv offered with new API, it’s possible use it instead slave-mode?
    Mplayer too old, mplayer2 is dead and mpv is young and alive: more commits, more releases, more fixes and improves. Smplayer is first good-enough GUI for mplayer for me, i very like it.
    I want keep smplayer on my laptop and all PC’s. Thanks a lot for basic mpv support, and i hope to see all mpv futures controlled by smplayer.