Everything has changed! Your old installations will break! Encodings will fail!

But in the end you’ll be able to install VapourSynth EVERYWHERE by typing pip install vapoursynth followed by vapoursynth config.

After that there are a few more optional commands you can find detailed in the updated installation instructions.

No more installers needed. Things will be neatly separated in every Python virtual environment. Everything will just work. Apart from migrating from your old installation. Plugins are now stored in a a subdirectory of the VapourSynth Python package. To get the new location run vapoursynth.get_plugin_dir() in Python. This will in the future allow all plugins and scripts to be installed through pip instead of VSRepo which over time will be phased out. NO PLUGINS WILL BE LOADED FROM THE PREVIOUS LOCATIONS!

Other Important Things

If you want to use VSRepo you now have to install it separately using pip (yes, pip install vsrepo is now possible). Likewise AVFS has been split off into its own repository and is now a separate download.

There still is a normal windows installer and the portable version install script if you prefer to still use them. Do however note that simply “upgrading” from R73 or earlier probably will break a lot of things due to the changes.

Why this didn’t happen earlier

This change has been requested for many years. Almost from the start ever since the Python module was packaged into a proper wheel. Due to a lot of factors this wasn’t even technically possible until recently. Or at least not without an insane testing workload.

The main improvement to Python that made this possible was the limited API which allows binary wheels to work on multiple Python versions without needing to compile a separate version for every release. This reduces the number of packages from over a gazillion to about 5. The limited API did however not have enough features until around Python 3.11-3.12 to accomplish this since VapourSynth uses memory views and such in its bindings.

And even if the pre-requisites are there you still have to figure out how to do it. VapourSynth is split into two main components, the core library written in C++ and VSScript, a library that embeds Python and abstracts script evaluation which is very hard to get right. If you’re paying attention you’ve now realized that VapourSynth is a library used by a Python module that is used by another library (VSScript) that embeds Python and is then in turn loaded by vspipe.

This is an almost circular dependency. Probably nothing else in existence does this. There are no Python tutorials covering this. Embedding Python is in and of itself something that feels more like an afterthought than something intended and creates many problems. Or to put it simply: it took this long to figure it out after Python 3.12 was released.

The time has finally come. I’ve been busy the past few months so all you get are a few bug fixes in another maintenance release. Also Visual Studio 2026 was released and its toolchain only support Windows 10 and newer. Likewise Cython is planning to soon drop support for Python 3.8 which is the last Python version to support Windows 7. Or to put it simply: Windows 7 is now getting much harder to support. The number of Windows 7 users is also much smaller now and just like the removal of 32 bit x86 builds this streamlines the build process quite a bit.

If anyone decides to produce legacy compiles tell me and I’ll link them but I suspect the market for those are very limited. I think that’s it. The upside is that clang-cl probably can be used to compile the next release and make it a bit faster.

Many poorly coded but popular Python modules like to write lots of junk directly to stdout. This is a big problem when piping from vspipe to another application and will break everything. On “not Windows” it was possible to use named pipes to get around this however on Windows you were stuck until now. To create a named pipe for output simply do vspipe script.vpy "\\.\pipe\<your pipe name>" and use the same “filename” as input for FFmpeg or recent x265 builds. A patch has also been submitted to x264 but hasn’t been accepted yet.

As mentioned in the previous posts every Python version starting with 3.12 is now supported in the Windows installer. This of course also includes Python 3.13 and 3.14 and will help people using poorly coded but popular Python modules that are slow to get support for for new Python versions.

There’s now an experimental version of VapourSynth that support Python 3.12 and later. This means 3.13 and the 3.14 pre-release as well. Windows binaries can be found here. It’s safe to use and is apart from the better Python support identical to the R71 release.

If no major issues are found this will become the standard distribution method for the windows installer in future releases starting with R72.

That and some bug fixes to the convolution filter. Not that exciting. Python 3.12 fans can safely skip upgrading.

Bug fixes again. Surprise! And some additional format constants. The most notable fixes are for a potential crash when splicing more than 2 audio clip and when resizing video by 0.5x using avx512.

In terms of user facing changes a few more format constants got added by popular demand and the VSScript API finally got a function to enumerate which output indices are actually set.

Lots of bug fixes, especially for audio handling. R67 is more or less a useless pile of regressions so avoid that one. There were a few mistakes made when converting lot of path handling code to C++17.

Also the ccf* and fm* enums in Python have been renamed. Or more exactly they were never supposed to be public in the first place. The one person affected by this has been informed there are no refunds.