R16 – The Slightly Less Broken Release

R15 had a serious issue that prevented the Avisynth compatibility stuff from working with anything except YV12, this release mainly fixes it. There isn’t much else new of interest in this release.

If you need more stuff to fidget with then go try the new resizers for VapourSynth too. They will most likely replace swscale once they become stable so testing is appreciated. They’re based on the dither tools code.

Next on my own todo list is a plugin to evaluate expressions at run-time, think mt_lutxy(z) but without insane memory requirements for 16bit formats. The other thing on the list mostly is about VSFS and that is to improve error handling and adapt the code to the latest Pismo File Mount API.

R15 – API Improvements

The time has come to break the API slightly to add some missing features. It also ends the alpha support discussion. The proper (and only) way to handle alpha is to return it as a separate mask clip. To make this easier filters now have a reasonably simple API to return more than one clip.

The new filters this time try to fill in some of the biggest feature holes, they are Merge, MaskedMerge and AVISource. MaskedMerge is very similar to masktool’s mt_merge in terms of functionality and the other two are very similar to the internal Avisynth filters with the same name. AVISource can of course open both VapourSynth and Avisynth scripts for import too.

There are also minor changes that need to be done to make plugins compile (binary compatibility with old plugins is however preserved). Previously the VSNodeRef type was always declared as const, this superfluous const declaration has now been removed everywhere in the API. Below are examples of the other two changes needed.

vsapi->setVideoInfo(a, b);
Change it to:
vsapi->setVideoInfo(a, 1, b);

The other construct that needs changing is filter creation which now automatically assigns itself to the out map:

cref = vsapi->createFilter(in, out, "Invert", invertInit, invertGetFrame, invertFree, fmParallel, 0, data, core);
vsapi->propSetNode(out, "clip", cref, 0);
vsapi->freeNode(cref);
Change it to:
vsapi->createFilter(in, out, "Invert", invertInit, invertGetFrame, invertFree, fmParallel, 0, data, core);

And don’t forget to check out my previous post with suggested tasks if you want to help out.

VapourSynth Tasks

I’ve hinted that there are plenty of things left to do before. Especially in my forum posts. Repeatedly. So in this post I’ll list some tasks I think should be done. Not all of them are programming either.

  • Proofread the documentation — most it was written after midnight so suggest clarifications too
  • Write testcases to cover more parts of the code — testing the python bindings is important too so only some scripting knowledge needed to help out with it
  • Add override file support to VIVTC (good entry level programming task)
  • Convert the EEDI3 port to pure C (simple if you know the difference between C and C++)
  • Port your favorite function/plugin from Avisynth — there’s something for everyone here
  • Port your favorite Avisynth script
  • Make a nice editor with preview — think AvsP
  • Write some simple getting started examples or maybe a quick introduction for Avisynth users
  • Add support for more output formats in vfw — clean up the output code too a bit
  • Write a good implementation of edge detection filters — canny, sobel and friends for higher depths would be nice
  • Your own ideas here

Minimum Requirements

I never mentioned the minimum requirements for VapourSynth. I completely forgot about it. It wasn’t until a poor ancient Athlon user reported crashes I remembered that I actually do have minimum requirements. So what are they? and why?

  • A CPU with SSE2 support (may be disregarded if not running on an x86 CPU)
  • XP SP3 or later (may be disregarded if not a windows user of course)

That’s it! Not so bloody. The rationale for only supporting XP and later mostly comes down to testing. There’s simply no one who uses older systems around to provide testing. Maybe my code will run,  maybe it won’t, but there’s no way to justify spending time testing it myself.

SSE2 on the other hand requires a bit more motivation. It’s very good to have when optimizing filters. Also, most CPUs support it today, it has reached the levels MMX support had 10 years ago or so. Every single x64 CPU must also support it. It’s everywhere.  And it’s good. For example the transpose function in VapourSynth runs a bit over 10 times faster with SSE2 optimizations.

I think that’s all I have to say about the minimum requirements. There’s always Avisynth for the few who don’t qualify.

R14 – Improved Packaging

It’s time for another release. The main highlights are bug fixes and the possibility to set the max cache size. The default max is 1GB everywhere to prevent running out of address space in 32bit applications. I’ve also decided to start bundling some potentially useful filters:

  • TemporalSoften – C code restored from inline asm
  • Histogram – with support for higher bitdepths in the default mode
  • VIVTC – think TIVTC but less features and portable
  • EEDI3 – improved to work on all 8bit formats

Since this project’s success depends a lot on good plugins being available I’ve also included all files needed to start developing in the installer. Just check out the SDK directory and the example invert filter to get started.

It’s now time for me to start spending more time porting/rewriting some useful Avisynth things…

R13 – Conditional Filtering and Memory Optimizations

It’s time for another release since it’s been over a week. The new things are a redone system for accessing frame properties and this time it’s less awkward and arcane, the possibility to write a full filter in python only (if you’re clever enough to figure out how to abuse ModifyFrame) and the memory management has been enabled. This means that VapourSynth will aggressively try to keep the amount of used framebuffer memory below 1GB to avoid running out of address space.

I also added all useful internal Avisynth filters turned into a standalone plugin to the downloads. It should make the transition to VapourSynth easier while waiting for your favorite internal filter to be ported. If your favorite filter happens to be a simple one I suggest you give porting it a try yourself.

As I feel the core is almost complete now I will focus on creating more automated regression tests, documentation everything and tweaking the automatic cache size adjustment for the next release. Phase one of the project is nearing the end. After that I will focus on porting popular filters properly, as in making them work on Windows, Linux and OSX in both 32 and 64bit mode. As some of you may have noticed I’ve already ported EEDI3 and I’m currently working on TIVTC, a difficult project (but not for the right reasons) which I’ll write another post about.

R12 – VapourSynth Takes a Step in The Enterprise Direction

This new version has something for everyone.  It has a round of bug fixes, one of them to the threading which means that it should be able to completely max out a 4 core CPU when running mdegrain2. The other features (requested through donations) are support for v210 output, the most used 10 bit format in professional video editing. To enable this output in VSFS and VFW add this to your script:

last = yourvideo
enable_v210=True

If you do not add it the output will default to P210. The documentation will be updated later today with more detailed installation instructions for VSFS. For those of you who can’t wait the install method is very similar to AVFS (just look for vsfs.dll).

R11 – VFW returns and Python 3.3

VFW has been debugged. Greatly. I’ve also added high bitdepth output support. However v210 shall be left out (I hate packed formats) unless someone contributes a patch or requests it in a donation message. VFW also has some behavioral changes such as returning a clip with colorful bars on error. This version also requires the Python 3.3 as this cuts down on the number of copies of visual studio I have to keep around.

Note that it is possible and quite easy to recompile the python and VFW modules for other versions. Maybe someone will contribute a python 2.7 compile one day.