Mpv: Compiling mpv with 'vapoursynth'

[fohrums]

mpv for windows: http://mpv.srsfckn.biz/

What's wrong with mpv-for-windows?

mpv for windows is made available via http://mpv.srsfckn.biz/ and by default doesn't come pre-compiled with vapoursynth.

Is it possible to start adding this pre-compiled? Otherwise how am I able to do this sort of thing?

REASON

• I want to be able to do _smoothmotion playback_.

  REFERENCE

• https://gist.github.com/phiresky/4bfcfbbd05b3c2ed8645

[kevmitch]

Questions of enabling vapoursynth in the the windows build aside, if by "smoothmotion", you mean something like madvr, then mpv has this built in with --vo=opengl:interpolation.
Your link refers to motion vector estimation which is an entirely different beast. Take a look at the wiki for more info.

[ghost]

From what I remember @lachs0r talking about VS, he doesn't add it to the Windows builds because compiling and making Python work on Windows is too much of a pain. I don't know if his Windows builds enable VS with the mpv Lua ad-hoc backend - if he does, you could port the Python script to Lua with some severe pain, but if you don't know what you're doing, I wouldn't recommend that.

[avih]

@fohrums you should know that mpv does support avisynth (if you use the mpv 32 build) and as such support SVP - which does the same kind of motion interpolation as the one at your reference. Not fun that SVP is closed source etc, but it does work.

[qyot27]

@fohrums you should know that mpv does support avisynth (if you use the mpv 32 build)

The 64-bit builds support it too, although I don't know if SVP is available in 64-bit so that 64-bit AviSynth+ can use it. svpflow apparently is available for 64-bit, but I don't know if that's all of it or not.

My own attempts at building VapourSynth for inclusion in the mpv build guide failed with C++ linking errors with zimg, and I haven't gone back to try figuring out why that happens yet.

[Maeyanie]

Sorry for ressurecting this old thread, but it's one of the top listings I found in Google looking for this, so seemed like a good place to post for other people searching.
I got the compile to work with mingw, with some effort. Mostly I followed the mingw/msys2 directions in compile-windows.md, and linked with the official VapourSynth Windows binaries by making some custom .pc files to tell waf where to find it.
If anyone is interested and lazy, you can download the copy I built, in 32-bit or 64-bit flavours, though I probably won't post updates (unless people really want it) so you'd be better off making your own anyhow.

Edit:
I've set up automatic building via Jenkins so updates will be happening after all.

[brachna]

Would love to have support for VapourSynth scripts in mpv builds on Windows.
@Maeyanie I assume you no longer update this? Jenkins page gives me an error.

[Vangelis66]

Happy New Year all! :santa:

@Maeyanie wrote:

I've set up automatic building via Jenkins, so updates will be happening after all.

OTOH, @brachna wrote:

I assume you no longer update this? Jenkins page gives me an error.

I can access the page OK currently, but the last successful mpv build was on Dec 14th 2017; this is "artifact" mpv32-20171214.7z, in fact mpv-0.27.0-535-git-20171212-g74c6e7b-i686; any more recent code fails to compile, probably because of changes upstream... 😞

Could you (Maeyanie) be kind enough to investigate this and (hopefully) come up with a fix?
I'm not that interested in the VapourSynth support itself (but surely it's a welcome addition), mostly in the fact your builds are Vista SP2 32-bit compatible, which is my current OS; official Win32 binaries (without VS support) offered at https://mpv.srsfckn.biz/ have ceased to run on Vista since mpv-0.26.0 (0.25.0 the last compatible version).
Most fortunately, (un)official builds by shinchiro have recently re-introduced Vista compatibility, but it's always best to have additional avenues open for Vista enabled builds... 😃

Best wishes for the New Year 2018 ! 🥂

[Maeyanie]

@Vangelis66: Recently mpv switched to a custom ffmpeg version, which broke the builds, but I got that all fixed for build 204. Just in time for them to switch back to the standard ffmpeg... which broke the builds again. ;)
I'll look into it now, and thanks for bringing it to my attention, I hadn't noticed.

Edit: Should be compiling again now. Until the next time something breaks.
By the way, if it ever stops working for you on Vista, please let me know. I checked into it and there doesn't seem to be any way to compile for a specific Windows version in MinGW, so it would probably depend on the MXE version I'm using, and that should be possible to revert to an older version and have everything still work.

[Vangelis66]

Happy New Year @Maeyanie !

Let me begin by thanking you immensely for your almost immediate response ! :+1:

thanks for bringing it to my attention, I hadn't noticed

You are most welcome...

Should be compiling again now. Until the next time something breaks.

Yes, I have been already able to grab both mpv32-20171231.7z (mpv-0.28.0-46-git-20180101-g4a6bb49) and mpv32-20180101.7z (mpv-0.28.0-48-git-20180101-ged6ae65), so indeed am very obliged...

For other people like me (without VapourSynth installed) wishing to try your builds, they do have a dependency on VSScript.dll to be able to even start to run; that DLL can be extracted from the portable archive found here (be sure to select the correct bit-depth) and placed besides mpv.exe; however, depending on your system, that DLL has additional dependencies on the following Microsoft DLLs: msvcp140.dll, vcruntime140.dll which are part of either MSVC++2015u3 (14.0.x.x versions) or MSVC++2017 (14.1x.x.x versions). If you don't have those two DLLs, install the respective MSVC++ Redistributables from MS; I, personally, prefer a portable mpv installation, so I just copied over those DLLs from my Mozilla Firefox 52.5.3 installation directory.

Having experimented with your latest mpv builds on my Vista SP2 laptop, one major issue I encountered is the inability to load the minimal OSD on the GUI (aka OSC); neither the new one nor the older one; it simply isn't there! I have performed tests also on my sister's Win7 x64 laptop, same there, so I suspect this issue isn't Vista related... My workaround is to use your mpv build inside the SMPlayer frontend, however having this fixed in standalone mpv would be highly welcome... FWIW, your very first mpv32 (shared) build you linked to previously in this thread, actually mpv-0.21.0-51-git-20161030-gbc77565-shared, doesn't suffer from this issue, i.e. the osd appears normally...

By the way, if it ever stops working for you on Vista, please let me know.

Kindly indicate the best place/way to do so... I fear the official mpv issue tracker, hospitable as it may be, doesn't strike me as the best place for that; I have browsed your GitHub pages and at first glance did not notice anything mpv related; nor did I find contact info inside the Jenkins pages...

As for mpv on Vista, have a read of the discussion in https://github.com/mpv-player/mpv/issues/4952; the official windows builds broke because of libarchive/schannel/bcrypt... :cry:

From the Jenkins page:

MXE’s default library set seemed alright for regular use,
but if you’d like to see any other features enabled in either mpv
or the ffmpeg it uses, feel free to let me know.

Actually, I'm seeing that youtube-dl integration (ytdl_hook) isn't enabled in your builds, while it is in the official (by lachs0r) and unofficial (by shinchiro) ones; since you're so kind to ask, this is a feature I'd like to see implemented too, if possible...

With regards to ffmpeg.exe, I have also been blessed to discover your builds here; unlike the official Zeranoe windows builds, yours remain Vista compatible (because they lack libx265, which is what breaks ffmpeg on Vista).

ffmpeg version N-89664-g2906363 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 5.4.0 (GCC)
configuration: --cross-prefix=i686-w64-mingw32.static- --enable-cross-compile --
arch=i686 --target-os=mingw32 --prefix=ffmpeg32 --enable-static --disable-shared
 --yasmexe=i686-w64-mingw32.static-yasm --disable-debug --disable-pthreads --ena
ble-w32threads --disable-doc --enable-avresample --enable-gpl --enable-version3
--extra-libs=-mconsole --enable-avisynth --enable-gnutls --enable-libass --enabl
e-libbluray --enable-libbs2b --enable-libcaca --enable-libmp3lame --enable-libop
encore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libspeex --ena
ble-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --e
nable-libvpx --enable-libx264 --enable-libxvid
libavutil      56.  7.100 / 56.  7.100
libavcodec     58.  9.100 / 58.  9.100
libavformat    58.  3.100 / 58.  3.100
libavdevice    58.  0.100 / 58.  0.100
libavfilter     7.  8.100 /  7.  8.100
libavresample   4.  0.  0 /  4.  0.  0
libswscale      5.  0.101 /  5.  0.101
libswresample   3.  0.101 /  3.  0.101
libpostproc    55.  0.100 / 55.  0.100

As you said, the mpv devs have gone back to ffmpeg-master code; on Sep 9th 2017, a basic MPEG-DASH demuxer was committed to ffmpeg-master:
https://github.com/FFmpeg/FFmpeg/commit/96d70694ae
This, in turn, has a dependency on the 3rd party lib "libxml2", which serves the role of external XML parser for the DASH manifests; this lib isn't enabled by default, so in order for the DASH demuxer to work, you have to explicitly configure "--enable-libxml2" during FFmpeg build time.
If this doesn't break anything mpv related, I would politely ask you add the "--enable-libxml2" config flag to your FFmpeg compiles; recent Zeranoe compiles have this enabled by default; it is unclear to me whether the mpv binary will then be able to play mpeg-dash streams, but having it enabled in the ffmpeg binary is a start...

Finally, closing this admittedly lengthy post, I want to apologise if I come across as a demanding person; this couldn't be farthest from the truth! I highly appreciate open source projects and am fully aware of the considerable personal time and effort open-source developers devote on their projects and, at the end of the day, the community of users; so I am not "demanding" anything here, more like writing down a wish list for Santa...

Many thanks again to all the mpv dev team and you for the pre-compiled windows builds!
Regards

[Maeyanie]

@Vangelis66: Sure thing, easy enough to do. Looks like both the missing OSD and youtube-dl integration are just a matter of adding Lua support, so compiles should now have both that and libxml2 added.

I also went and added my e-mail to the Jenkins page. I'm sure every spam bot in the world has it already, so no point in hiding.

It's interesting that libx265 breaks Vista support for them but not me, as I actually am including that. My guess is it's because I'm compiling it with MinGW as part of the MXE libraries, where they're either using a Windows binary, or compiling it with MSVC.

That, or I had an older version, which will now promptly break everything as I've just updated it as part of this.

[ArcAngelRyse]

hey I just downloaded your bundle, curious I'm getting an error with libzimg.2.dll, say's its not found. any how on to fixed this? Would be greatly appreciated been working on this all day.

[Maeyanie]

It looks like the compiles right now are missing a number of DLLs, which is odd since it's supposed to be a static compile. I'll look into it, thanks for letting me know.

Edit:
Looks like when I switched to a Docker-based Jenkins setup I accidentally compiled a shared library for zimg there, and it was using that instead of the static one. Should be fixed now.

[ArcAngelRyse]

It looks like the compiles right now are missing a number of DLLs, which is odd since it's supposed to be a static compile. I'll look into it, thanks for letting me know.

Edit:
Looks like when I switched to a Docker-based Jenkins setup I accidentally compiled a shared library for zimg there, and it was using that instead of the static one. Should be fixed now.

Domo arigatou! ~Thank you.

I'll download the update.

[ArcAngelRyse]

I fixed by putting all the dll's I had because I was building mines, but I still haven't noticed how to get this realmotion "motioninterpolation.py" to work whenever I attempt to change the filter unfortunately it tells me it's fails in mpv.

[Vangelis66]

@Maeyanie wrote:

I accidentally compiled a shared library for zimg there,
and it was using that instead of the static one. Should be fixed now.

First, many thanks for fixing the libzimg-2.dll dependency issue ✌
However, it turns out something else's gone awry:
Prior to your intervention, whenever changes were committed to the ffmpeg source, a new mpv build was triggered (even when the actual mpv source hadn't changed); that way, the most current compile of mpv had always the most up-to-date code snapshots of both ffmpeg+mpv repositories...

Now, a new mpv build isn't auto-triggered... In
https://jenkins.maeyanie.com/job/mpv/350/
it was the last time that happened due to an update of the ffmpeg source:

Changes in dependency ffmpeg #264 → #274 (detail)

  | Started by an SCM change

In both
https://jenkins.maeyanie.com/job/mpv/351/
https://jenkins.maeyanie.com/job/mpv/352/
mpv compilation due to a simple ffmpeg update was manually initiated:

No changes. Changes in dependency ffmpeg #282 → #283 (detail)

  | Started by user Maeyanie

FFmpeg is already now on Build #284, but an mpv Build #353 based on that is nowhere to be found...
Will you be kind enough to have a look, please?

One other thing about zimg; you said that (now) mpv compilation uses a static zimg lib; AIUI, zimg is a dependency of the zscale video filter (-vf zscale); but when I type

mpv --vf=help | FindStr zscale in your latest binary, I get nothing... Similarly,
mpv --vf=zscale=help prints Filter 'zscale' not found.

By contrast, in shinchiro's (Vista compatible) builds, I get:

>mpv --vf=help | FindStr zscale
  zscale           Apply resizing, colorspace and bit depth conversion.

What gives?

Thank you immensely, once again, for providing Windows Vista SP2 compatible ffmpeg+mpv binaries 👍
OT: May you have the Merriest Christmas and the Happiest New Year, too!

[Maeyanie]

However, it turns out something else's gone awry:
Prior to your intervention, whenever changes were committed to the ffmpeg source, a new mpv build was triggered (even when the actual mpv source hadn't changed); that way, the most current compile of mpv had always the most up-to-date code snapshots of both ffmpeg+mpv repositories...

Seems the Jenkins "build after" setting got unset, not sure how, I didn't touch any of that. It's set again now, hopefully it continues working.

One other thing about zimg; you said that (now) mpv compilation uses a static zimg lib; AIUI, zimg is a dependency of the zscale video filter (-vf zscale); but when I type

mpv --vf=help | FindStr zscale in your latest binary, I get nothing... Similarly,
mpv --vf=zscale=help prints Filter 'zscale' not found.

By contrast, in shinchiro's (Vista compatible) builds, I get:

>mpv --vf=help | FindStr zscale
  zscale           Apply resizing, colorspace and bit depth conversion.

What gives?

Looks like ffmpeg needs to be compiled with "--enable-libzimg" for that filter to exist. From what I can see (it's been a while since I set all this up) previously it was VapourSynth requiring it and pulling it into the compile.
I'll add that flag now, shouldn't cause any problems, and the library is there anyhow.