All code is bug free until someone else tries to run it. It’s a scientific fact!
This release fixes all known resizer issues that have been discovered so far. Fortunately none of them led to image corruption, just incorrect rejection of certain conversions.
And it can’t be a release without warning about something that’s slightly changed in some way. So here comes the warning. The installer now writes the registry keys related to the 64bit version into HKLM64 which makes more sense. All the old entries will also be kept until everyone has switched to the new ones. This is in preparation of the day the 32bit VapourSynth windows version stops existing, which unfortunately won’t be anytime soon despite it being over 12 years since we got x64.
Other possible titles:
- DEATH TO… Installers?
- More Avisynth than Avisynth
- Improvements to Reduce Seeking in Source Filters
Welcome to the glorious even numbered release of R30! A release with so many new things a single topic cannot do it justice.
The first point proves that sometimes less is more. There’s now a version for windows that doesn’t need to be installed. It’s used together with embeddable Python and allows vspipe to be used for output. It’s also possible to use the VapourSynth Editor with it by putting it in the same directory.
For those of you who still can’t live without certain Avisynth filters there are great news. Avisynth 2.6 plugins are now supported in both 32 and 64 bit builds. Note that 64 bit builds can’t use 2.5 plugins. Which isn’t a real problem since almost none exist anyway.
And finally the performance related change. This continues the work in R29 of making the time it takes to produce a single frame more consistent. Plugins can now signal that they prefer to have frames requested in sequential order, if possible, and a reasonable effort will be made to make it that way. This fixes most of the remaining possible slowdowns to in scripts because the source filter has to search too much. Note that new source filter builds are needed which will be out soon. FFMS2, d2vsource and L-SMASH works will be released with support for this in a few days… or weeks.
Of course there are some other small fixes too but they aren’t really interesting enough to list here.
Possibly breaking changes:
The resize functions have their default behavior changed to make the colorimetry arguments override the frame properties by default. Previously the frame properties would always take precedence when present. To restore the old behavior set prefer_props.
PlaneDifference is completely removed and PlaneAverage will be completely removed in R32. They’re both replaced by PlaneStats which can calculate multiple metrics at once with no speed penalty.
Now all you installer haters and permission deprived grumpy people can switch from Avisynth too!
Simply decompress and overwrite all existing files on top of an embeddable Python copy.
Links to the binaries are in this doom9 thread.
Portable binaries will probably be posted for all future released if there’s any demand at all.
I released a filter idea that’s been collecting dust for a while. Download link and sample pictures can be found in this doom9 thread.
Gingerbread processed with VapourSynth
Don’t forget to de-rainbow your gingerbread. And throw it away immediately if there are dots crawling on it.
Today is a great day. SWScale is no longer the default resizing library included with the core. Instead the much more accurate zimg library is now the default. This means a few new resize algorithms are available and there are many new options. The change has been made to break as few scripts as possible but there is one important difference, since YUV has so many different variants, the matrix to use always has to be specified when converting to YUV and it also sometimes has to be specified when converting from YUV.
Will always work:
c = core.resize.Bilinear(c, format=vs.YUV420P8, matrix_s="709")
Will now only work if c is a YUV clip:
c = core.resize.Bilinear(c, format=vs.YUV420P8)
Likewise this will always work for YUV input:
c = core.resize.Bilinear(c, format=vs.RGB24, matrix_in_s="709")
But this will only work with YUV input if the proper matrix is set as a frame property:
c = core.resize.Bilinear(c, format=vs.RGB24)
There are also many other fixes and changes such as:
- More consistent performance with many threads
- Various VIVTC fixes
- R28 would sometimes misdetect Python paths and fail
- More specific error messages in most core filters
What’s controversial you ask? Checking if plugins actually use the API as documented. Walls of derping on the subject were quickly created. But enough about that, now it’s time to list the new features and interesting changes.
The first thing you’ll notice is that Python 3.5 is now required instead of 3.4. This is good because it’s not bad. And I don’t have to keep an ancient compiler around anymore when developing things. Windows development only needs VS2015 now.
Other interesting changes are:
- Expr is much faster because it has runtime code generation – there should be much less reason to use Lut(2) now
- Expr can have 26 input clips – many instances of Lut2 and other small logic filters can now be folded into one much faster expression
- Float support in PlaneAverage, imwri, Lut and Lut2 (only output in the lut filters)
- “vs.get_core()” can be used everywhere in scripts – previously it would throw an error if used in script function callbacks
- Much smaller installer
And remember, this project doesn’t run on e-recognition. It runs on despair and hate on interweb forums. Occasionally supplemented by small donations.
There are now fairly stable test builds for R28 available. Don’t forget to install Python 3.5 first.
Recently there’ve been several users that encountered problems after installing VapourSynth. I imagine that those users looked something like this:
Huh? What’s an update?
Don’t be this guinea pig. Use windows update. Install
KB2533623 all available updates (or only Internet Explorer 11 since that seems to pull in the required ones) and don’t be afraid of new things.
There’s some kind of theme to this release but I’m not sure what it is. Maybe I should say it’s all about fixing past mistakes since the majority of GenericFilters got rewritten and integrated into the core. The original code quality was simply too low and there were small bugs and differences littered all over it.
Or maybe it’s about streamlining the API to have fewer odd cases to deal with. The so-called “unknown length” clips have now been deprecated and trying to return one from a filter will trigger an error. All potential uses of it can simply be replaced with one very long clip. No reason to keep unnecessary complexity around.
There’s also been a big effort put into making the frame properties mean something and for them to be used. Now most filters will automatically use the flagged field order when present, the order specified in filter arguments will only be used if no valid order is set. There’s also more color information provided so colorspace converters can automatically pick the right input format. To make this work you’ll need to update to the latest fmtconv and FFMS2 builds. The z library will probably be updated soon too.
Important Compatibility Information
The API version has been increased to 3.2 to show that unknown length clips are no longer available. This means plugins compiled against the new header won’t work with older versions.
The plugin version of GenericFilters will be removed in the next release so start changing all scripts to use the equivalent functions in the std namespace instead.