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.

Jeeb’s patch to add the high bitdepth y4m formats has now made its way into x264. This means that you can now use y4m for 10 bit input too and save the trouble of manually specifying the input properties.

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…

Go to the VirtualDub forum to to get it and try it out.

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.

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).

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.

Another few days have passed and the VFW module is now ready for a first test out in reality. It supports all the same output formats as Avisynth 2.6 plus one more! (which you will probably never use) I have decided that the official extension for these virtual avi scripts should be .vpy. Think Video PYthon script to remember it. It was the best I could come up with that wasn’t used by something else as well. The VFW part has been tested with AVISource in Avisynth, MPC-HC and VirtualDub. Out of these VirtualDub is the only one that needs a small workaround since it detects the special compatibility mode based on file extension, you MUST SELECT the compat option in the File\Open dialog or it won’t open.

Of course there’s also a bunch of other changes such an installer that comes with all the needed runtimes, the usual pile of  Python module fixes and other things. Release early, Release often as the saying goes. My schedule is to try to make a new release every time I cross off something on the todo list.

I have also added a donation button. At least consider using it. Click on it once and then quickly close the window if you don’t want to donate anything. I will however never threaten to stop the project or anything else that’s close to drama if donations are low.

This is the big release. The new things are:

• Full documentation of all the included functions
• The full source released as LGPL
• Fixes bugs in most of the internal filters
• Adds Python + operator and slicing support to clips
• Fully working on linux (and probably osx too if you want to try compiling there)
• Many other small things like more fixes to y4m output

With this release I consider the API stable and the core mostly feature complete. So start writing and porting plugins!

What’s next on the todo list (in no particular order):

• Write a masktools replacement (probably with asmjit)
• Write a general subtitling plugin, something like AssRender for Avisynth
• Figure out what to do about the horrible resizers
• Write a vfw module
• Make it possible to write full plugins and not just functions in Python
• Document the C API and make a small example of how to write an Invert filter
• Other stuff

The title says it all, I hoped to have a bit more ready but this is at least a bit over halfway to my stated goals.

The big news is the addition of a function type. This allows some interesting things like this:

def selector1(sdict):
 a = sdict['N']
 a = a % 2
 b = {'val':a}
 # return the index of the clip to select
 return b

def selector2(sdict):
 # for these functions the key 'N' holds the requested frame number
 # and FX corresponds to the index of the frames
 frame_properties = get_props(sdict['F0'])
 if frame_properties['SomeFrameProperty'] < 0.5:
 return {'val':0}
 else:
 return {'val':1}

# some source for clip0 and clip1 here
ret = core.std.SelectClip(clips=[clip0, clip1], src=[clip0], selector=selector1)

# ret will now return every other frame from clip0 and clip1 interleaved

# selector2 shows how frame properties can be factored into it