Vapoursynth

[Mystery Keeper]

"planes:int[]: opt:empty;" <- you probably don't want empty there, it's most likely an error if a user wants to filter no planes

Actually intentional for testing purpose. Thank you for advices!
Also, silly me. Didn't free write pointers. That would cause a memory leak, so if anyone's already using it - you should update.

[handaimaoh]

And finally, someone started (https://github.com/handaimaoh/vsremovedirt) to port RemoveDirt to VS. :)

And it's getting close. I've ported it enough that it compiles. I just need the next couple of days to get the ASM ported to intrinsics (and most of it is pretty straightforward so it shouldn't be too hard) then to test it. The only other thing is that kassandro's RemoveDirt script (as of versions .8 and above it's merely a script around some functions in RemoveDirt and RemoveGrain) for Avisynth requires modes 16 and 17 in RemoveGrain. So before it can be used I'll work on implementing those modes for vsremovegrain since it currently doesn't support those modes.

[Reel.Deel]

Hi handaimaoh, welcome to the forum. :)

Great news about your progress/plans for RemoveDirt.
Regarding SCSelect what's your thoughts about adding functionality to be able to output a scene change log
and also make it compatible so that other plugins can use it as their scene change detector? (Similar to Chikuzen's scenechange plugin (http://forum.doom9.org/showthread.php?t=166769))

[Myrsloik]

Hi handaimaoh, welcome to the forum. :)

Great news about your progress/plans for RemoveDirt.
Regarding SCSelect what's your thoughts about adding functionality to be able to output a scene change log
and also make it compatible so that other plugins can use it as their scene change detector? (Similar to Chikuzen's scenechange plugin (http://forum.doom9.org/showthread.php?t=166769))

SCSelect should never be ported. It's trivial to write as a script using FrameEval and PlaneDifference. It only calculates the sum of absolute differences to make its decision.

Note that Chikuzen's scenechange plugin also uses the absolute difference and should produce almost identical results. If you want the relative threshold mode as well just write a feature request Chikuzen.

[handaimaoh]

Yeah, it will likely just get removed. It was only ported over simply for being able to test everything and the fact that it was like 2 minutes of effort since it was pretty simple.

[cretindesalpes]

SCSelect [...] only calculates the sum of absolute differences to make its decision.
Does it? The documentation states otherwise, Didée too (here (http://forum.doom9.org/showthread.php?p=1607246#post1607246)). I have to say that 2nd order differences are much more reliable, from my experience. Anyway, I don’t know if it’s better to compute the scene change using 3 input frames each time (dedicated plug-in) or to save the first order differences on additional temporary frames, wasting memory for these trivial operations.

[Myrsloik]

Does it? The documentation states otherwise, Didée too (here (http://forum.doom9.org/showthread.php?p=1607246#post1607246)). I have to say that 2nd order differences are much more reliable, from my experience. Anyway, I don’t know if it’s better to compute the scene change using 3 input frames each time (dedicated plug-in) or to save the first order differences on additional temporary frames, wasting memory for these trivial operations.

The relevant code for selecting:
if( dirmult * olddiff < lastdiff ) goto set_end;
if( dirmult * lastdiff < olddiff ) goto set_begin;
olddiff and and lastdiff are the absolute difference to the previous/next frame. I suppose that does make it second order but it's still trivial to recreate.

[mastrboy]

There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...

[handaimaoh]

There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...

Before any final decision is made I'll do some speed tests. If SCSelect is still substantially faster it'll be kept around until something else can replace it. It's not a ton of code as is.

[StainlessS]

SCSelect_Like function in script (behaves identically and not very good) from here:- http://forum.doom9.org/showthread.php?p=1644023#post1644023


Avisource("D:\avs\test.avi")

# RemoveDirt's SCSelect(clip input, clip scene_begin, clip scene_end, clip global_motion, float dfactor, bool debug, bool planar)

Function SCSelect_Like(clip dclip,clip Start,clip End,clip Motion, float "dfactor",bool "debug") {
# Start, End, Motion MUST all be same, dclip can be other colorspace/size (unlike SCSelect).
dfactor=Float(Default(dfactor,4.0))
debug=Default(debug,false)
Global SCM_A=0.0 Global SCM_B=0.0 Global SCM_SC=0 Global SCM_Prev=-1
Motion.ScriptClip("""
NotNext = (current_frame!=SCM_Prev+1)
Global SCM_A=(NotNext)? RT_LumaDifference(dclip,dclip,n=current_frame-1,n2=current_frame) : SCM_B
Global SCM_B= RT_LumaDifference(dclip,dclip,n=current_frame,n2=current_frame+1)
# 0 = Start of scene, 1 = End of scene, 2 = Global motion
Global SCM_SC=(current_frame==FrameCount-1)?1:(SCM_A>dfactor*SCM_B || current_frame==0)?0:(SCM_B>dfactor*SCM_A)?1:2
(SCM_SC==0) ? Start : (SCM_SC==1) ? End : Last # Choose Start, End or Motion(ie Last)
(debug)?RT_Subtitle("%d ] %6.2f %6.2f SC=%d",current_frame,SCM_A,SCM_B,SCM_SC):NOP
Global SCM_Prev=current_frame
Return Last
""",args="dfactor,Start,End,Dclip,debug") # Needs Grunt for args
return Last
}

Start=Subtitle("START OF SCENE",align=3,size=30)
End=Subtitle("END OF SCENE", align=1,size=30)
Motion=Subtitle("GLOBAL MOTION",align=5,size=30)
L=SCSelect_Like(Last,Start,End,Motion,debug=true)
R=SCSelect(Last,Start,End,Motion)
StackHorizontal(L,R)

[Myrsloik]

There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...

I think most of the speed difference is because avisynth recalculates the metric for both frames if you use scriptclip and friends. In vapoursynth the metric would be attached to frames and cached.

Experimentation welcome. Just keep in mind i didn't write any asm for the vapoursynth functions planedifference and planeaverage yet so for now it will be slightly slower.

[Are_]

On latest git from vapoursynth:
Python 3.3.2 (default, Aug 18 2013, 22:19:13)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
terminate called after throwing an instance of 'std::regex_error'
what(): regex_error
Aborted

It looks like it's compiler's fault. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631)

Anybody knows if this is supported on other compilers (4.9 looks far away for me)?

[Myrsloik]

On latest git from vapoursynth:
Python 3.3.2 (default, Aug 18 2013, 22:19:13)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
terminate called after throwing an instance of 'std::regex_error'
what(): regex_error
Aborted

It looks like it's compiler's fault. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631)

Anybody knows if this is supported on other compilers (4.9 looks far away for me)?

I use it for some trivial checks so I'll just rewrite it without regexp. I believe clang implements everything properly. Or you can just wait a day or two and I'll have it unbroken. There are like 0 functionality changes since r21, only cleanups and rewrites.

[Are_]

Nice to know there's an easy fix. Thx :)

[Myrsloik]

Nice to know there's an easy fix. Thx :)

I should be fixed now, I guess. Report any other new linux issues you find.

[Joachim Buambeki]

Great work so far Myrsloik. :-)

What about making Vapoursynth OpenFX (http://openfx.sourceforge.net/) compatible?
That would open the power of Vapoursynth to a lot of users, professionals and users of the free but powerful Resolve Lite but I am sure users of other apps like Nuke etc. would would also profit from it.

JB

[kolak]

This is a nice idea :)

[Myrsloik]

Great work so far Myrsloik. :-)

What about making Vapoursynth OpenFX (http://openfx.sourceforge.net/) compatible?
That would open the power of Vapoursynth to a lot of users, professionals and users of the free but powerful Resolve Lite but I am sure users of other apps like Nuke etc. would would also profit from it.

JB

To do what exactly? Be a simple source plugin?

[Are_]

If I prevent removegrain from building everything works great (also just as an informative note, clang throws the same error at runtime when regex are used).

gcc and clang complain on the new code:
gcc buildlog (http://pastebin.kde.org/pu5bupozn/prfcz5)
../src/filters/removegrain/clense.cpp:152:19: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
d.mode = (int)userData;
clang buildlog (http://pastebin.kde.org/pfi7ekydp/cvssz8)
../src/filters/removegrain/clense.cpp:152:14: error: cast from pointer to smaller type 'int' loses information
d.mode = (int)userData;
^~~~~~~~~~~~~
1 error generated.
../src/filters/removegrain/removegrainvs.cpp:1241:3: error: constant expression evaluates to -294912 which cannot be narrowed to type 'uint32_t' (aka 'unsigned int') [-Wc++11-narrowing]
{ -0x8000 * 9, -0x8000 * 9, -0x8000 * 9, -0x8000 * 9 };
^~~~~~~~~~~
../src/filters/removegrain/removegrainvs.cpp:1241:3: note: override this message by inserting an explicit cast
{ -0x8000 * 9, -0x8000 * 9, -0x8000 * 9, -0x8000 * 9 };
^~~~~~~~~~~

[Joachim Buambeki]

To do what exactly? Be a simple source plugin?
I am not sure what you mean with "source plugin", but my idea was to select Vapoursynth as a filter in the host application and then you can open a console or something similar where you can type in the filter effect (without the import video stuff of course because it does that automaticaly).
What would be even cooler if it would be possible if one could create wrappers to directly call a certain filter (script) from Vapoursynth like a regular plugin.

A similar suport for After Effects would be great but that would mean that a separare plugin would have to be written, since AE isn't OpenFX compatible unfortunately.


I can only guess but support for these applications should also speed up development of Vapoursynth alot if communicated through the right channels (forums where those people are - CreativeCow, LiftGammaGain, etc.). There should be a fair amount of pros that would be willing to donate their time to help with development I suppose.

[Mystery Keeper]

I'm trying to write a VapourSynth Python script function. When I pass an argument as None, I want AviSynth filter to use the default value for that argument. How can I do that? Can I form a string of AviSynth filter call and "Evaluate" it?

[Myrsloik]

I'm trying to write a VapourSynth phyton script function. When I pass an argument as None, I want AviSynth filter to use the default value for that argument. How can I do that? Can I form a string of AviSynth filter call and "Evaluate" it?

Something like this can be done in python:
d = dict(arg1=1, arg2=2) #args you always set here
if arg3 is not None: # optional arg that shouldn't be set when None
d['arg3name'] = arg3
clip = core.avs.AvsFunction(**d)

[Mystery Keeper]

Awesome! I can actually specify different AND matching arguments for multiple calls that way. Thanks a lot, Myrsloik!

[Mystery Keeper]

1) Is there mt_diff analog for VapourSynth? I can do it like this:
def absdiff(x, y):
return min(max(0, 127 + x - y), 255)

diff = core.std.Lut2([a, b], function = absdiff)
But it is bitdepth-specific and likely not very fast.

2) Is there HistogramAdjust analog for VapourSynth, or should we ask the author for port?

[Myrsloik]

1) Is there mt_diff analog for VapourSynth? I can do it like this:
def absdiff(x, y):
return min(max(0, 127 + x - y), 255)

diff = core.std.Lut2([a, b], function = absdiff)
But it is bitdepth-specific and likely not very fast.

2) Is there HistogramAdjust analog for VapourSynth, or should we ask the author for port?

1. No

2. No again

[Mystery Keeper]

AvsPMod silently crashed after several minutes of experimenting with this script. VirtualDub silently crashed after processing ~120000 of ~150000 frames.
Script uses this function. (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/MCDenoise.py?at=master)

avisynth_plugins_path = 'E:\\avisynth-plugins\\'
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'

import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)

core.set_max_cache_size(3500)

import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
core.std.LoadPlugin(vapoursyth_plugins_path + filename)

core.avs.LoadPlugin(path = avisynth_plugins_path + 'mvtools2.dll')

core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x32\\templinearapproximate.dll')

d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'

ret = core.d2v.Source(input=d2vfile)

def pcToTv(input):
c = core.fmtc.resample (clip=input, css="444")
c = core.fmtc.matrix (clip=c, mats="601", matd="709")
c = core.fmtc.resample (clip=c, css="420")
c = core.fmtc.bitdepth (clip=c, bits=8)
return c

z = pcToTv(ret)

sys.path.append('D:\\Programming\\TempLinearApproximate-VapourSynth\\')
import MCDenoise

tlamc = MCDenoise.MCDenoise()
tlaArguments = dict(radius=2, BlockSize=8, Overlap=4, SubPel=4, SubPelInterp=2, Search=5, SearchParam=2, PelSearch=4, DCT=10, ThSAD=200)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = core.f3kdb.F3kdb(ret, dither_algo=2, grainy=0, grainc=0, keep_tv_range=True)

ret = pcToTv(ret)

ret.set_output()

def absdiff(x, y):
return min(max(0, 127 + x - y), 255)

unfiltered = core.text.Text(z, "unfiltered")
filtered = core.text.Text(ret, "filtered")
stack = core.std.StackHorizontal([unfiltered, filtered])
diffhist = core.std.Lut2([z, ret], function = absdiff)
#diffhist = core.generic.Levels(diffhist, planes=0, gamma = 3)
diffhist = core.text.Text(diffhist, "Difference")
filteredhist = core.generic.Levels(ret, planes=0, gamma = 2)
filteredhist = core.text.Text(filteredhist, "Filtered amplified")
diffstack = core.std.StackHorizontal([diffhist, filteredhist])
compare = core.std.StackVertical([stack, diffstack])
#compare.set_output()

[Myrsloik]

AvsPMod silently crashed after several minutes of experimenting with this script. VirtualDub silently crashed after processing ~120000 of ~150000 frames.
Script uses this function. (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/MCDenoise.py?at=master)


Did you notice anything like the memory use going up or the script getting slower over time?

[Mystery Keeper]

The processing speed fluctuates relatively much. 5-11 FPS. But I don't know about the time when it crashed. Is there a way to profile at least the memory use without having to constantly monitor it? Is it possible to have on demand FPS and memory usage profiling and logging functionality in VapourSynth?

[Myrsloik]

The processing speed fluctuates relatively much. 5-11 FPS. But I don't know about the time when it crashed. Is there a way to profile at least the memory use without having to constantly monitor it? Is it possible to have on demand FPS and memory usage profiling and logging functionality in VapourSynth?

Never mind. I saw that you sneakily put a dll of TLA there.

[Mystery Keeper]

Right, sorry. Restarted the encode with memory limit changed to 2500. 9K frames so far. Memory usage isn't going over 840MB, but IS slowly rising.
Update: 100000 frames. Still the same fluctuating bitrate. Memory usage still not going over 840MB.

[Myrsloik]

Right, sorry. Restarted the encode with memory limit changed to 2500. 9K frames so far. Memory usage isn't going over 840MB, but IS slowly rising.
Update: 100000 frames. Still the same fluctuating bitrate. Memory usage still not going over 840MB.

You are running it from a command prompt, right? That way it will usually at least print a fatal error message to stderr. It could be that it simply went over the limit very shortly. I would never try to run it with a memory limit over 2GB since that's only the limit for when memory begins to get reclaimed. Combined with allocations inside filters you're still dangerously close to 3GB if you set it to 2.5GB.

[Mystery Keeper]

Nope. I'm simply encoding it in VirtualDub GUI. Right now it is over 145000 frames, and is still using around 830MB. No idea why it would crash back then.
Update. It has suddenly and silently crashed again.

[Myrsloik]

Nope. I'm simply encoding it in VirtualDub GUI. Right now it is over 145000 frames, and is still using around 830MB. No idea why it would crash back then.
Update. It has suddenly and silently crashed again.

Try doing the encoding with vspipe next time. That way you'll most likely see the fatal error printed. I'm going to try your script now myself and see what happens...
What's the resolution of your source?

[Mystery Keeper]

Quite ordinary 720x480 NTSC DVD.

[handaimaoh]

RemovePort is now done being ported and converted to intrinsics. If you want to test it out a binary is here (https://www.dropbox.com/s/omou1kyr8xgodkk/RemoveDirt.dll). I have not really tested it much so far so please let me know of any issues.

A simple Vapoursynth script to test would look like the following if your clip is not greyscale:


clip = core.ffms2.Source(src)
cleansed = core.rgvs.Clense(clip)
sbegin = core.rgvs.ForwardClense(clip)
send = core.rgvs.BackwardClense(clip)
scenechange = core.vsrd.SCSelect(clip, sbegin, send, cleansed)
alt = core.rgvs.Repair(scenechange, clip, mode=[16,16,1])
restore = core.rgvs.Repair(cleansed, clip, mode=[16,16,1])
corrected = core.vsrd.RestoreMotionBlocks(cleansed, restore, neighbour=clip, alternative=alt, gmthreshold=70, dist=1, dmode=2, noise=10, noisy=12, grey=0)
clip = core.rgvs.RemoveGrain(corrected, mode=[17,17,1])
clip.set_output()

If it is greyscale change the second value in the mode array of ints to -1. A more fancy function will be knocked up later.

Works with only YUV420P8 and YUV422P8 right now.

[easyfab]

I try vapoursynth for the first time. It's a little bit harder than avisynth.
But I succeed to run a script with qtgmc() thanks to aegisofrime script example http://forum.doom9.org/showthread.php?p=1649699#post1649699

although the cpu usage is 100% ( compare to ~50% with my avs script ) the speed is slower for x264 encoding ???
Are some plugins less optimized yet ?

Another question:
Is there a special way to load yadif.dll ? because it doesn't work for me

core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll')
core.avs.Load_Stdcall_Plugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll') ?

And if someone can give me a script example for yadifmod with edeint=nnedi3 It would be nice.

Vapoursynth look promising for the futur, I will keep an eye on it .

[Myrsloik]

I try vapoursynth for the first time. It's a little bit harder than avisynth.
But I succeed to run a script with qtgmc() thanks to aegisofrime script example http://forum.doom9.org/showthread.php?p=1649699#post1649699

although the cpu usage is 100% ( compare to ~50% with my avs script ) the speed is slower for x264 encoding ???
Are some plugins less optimized yet ?

Another question:
Is there a special way to load yadif.dll ? because it doesn't work for me

core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll')
core.avs.Load_Stdcall_Plugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll') ?

And if someone can give me a script example for yadifmod with edeint=nnedi3 It would be nice.

Vapoursynth look promising for the futur, I will keep an eye on it .

Avisynth C plugins can't be loaded. Only normal 2.5 API ones work. Exactly what were your QTGMC and x264 settings when testing it?

QTGMC is known to be a bit slower than when run in avisynth-mt at its best but the difference should be around 15% or so at most.

[Myrsloik]

Quite ordinary 720x480 NTSC DVD.

Did you overclock your computer or look at the core temperature at all when running the script? Just curious.

[Mystery Keeper]

Did you overclock your computer or look at the core temperature at all when running the script? Just curious.

Nope. Water cooled and not overclocked.

[Myrsloik]

Nope. Water cooled and not overclocked.

Running the script with a blankclip source now. Will see if it can pass 500000 frames in a couple of hours. Days like these I wish I'd gone with a 3770k cpu...

[Mystery Keeper]

That's why I'm saving for two 12 cores Xeons ^_^'

[easyfab]

Avisynth C plugins can't be loaded. Only normal 2.5 API ones work. Exactly what were your QTGMC and x264 settings when testing it?

QTGMC is known to be a bit slower than when run in avisynth-mt at its best but the difference should be around 15% or so at most.

For vapoursynth ( 100% cpu usage )
clip = haf.QTGMC(clip, Preset='slow',TFF=True)
clip = clip[::2]

and for avisynth (~50-60% cpu usage )

setmtmode(2)
QTGMC(preset="slow", EdiThreads=4).selecteven()

x264 --preset slower

And speed is about 20% less with vapoursynth

[mastrboy]

Running the script with a blankclip source now. Will see if it can pass 500000 frames in a couple of hours. Days like these I wish I'd gone with a 3770k cpu...

Now I'm curious, what did you get instead?

[Myrsloik]

Now I'm curious, what did you get instead?

The 3570k, because at the time I hadn't decided to work on very multithreaded things like VapourSynth. Maybe Intel will give me something better if I ask nicely...

Anyway, next investment will be a very fast graphics card that doesn't sound like a vacuum cleaner.

If someone happens to have a computer with lots of cores I could use remotely to test VapourSynth on that'd be very useful. It's hard for me to test how well things scale on lots of cores with only 4 here.

[Myrsloik]

Quite ordinary 720x480 NTSC DVD.

506k frames later and it still works. I don't think this method of testing will yield anything. I'll add logging of fatal errors and then let you try that build.

[Reel.Deel]

RemovePort is now done being ported and converted to intrinsics. If you want to test it out a binary is here (https://www.dropbox.com/s/omou1kyr8xgodkk/RemoveDirt.dll). I have not really tested it much so far so please let me know of any issues.

When I try to load RemoveDirt I get this error:
---------------------------
VirtualDub Error
---------------------------
Python exception: 'Failed to load C:\\RemoveDirt.dll'
Traceback (most recent call last):
File "vapoursynth.pyx", line 1082, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:16736)
File "C:\test.vpy", line 4, in <module>
core.std.LoadPlugin(path=r'C:\RemoveDirt.dll')
File "vapoursynth.pyx", line 1005, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:15793)
vapoursynth.Error: 'Failed to load C:\\RemoveDirt.dll'



Also, since clense is now included with RemoveGrainVS shouldn't the script look something like this instead?
clip = core.ffms2.Source(src)
cleansed = core.rgvs.Clense(clip)
sbegin = core.rgvs.ForwardClense(clip)
send = core.rgvs.BackwardClense(clip)
scenechange = core.vsrd.SCSelect(clip, sbegin, send, cleansed)
alt = core.rgvs.Repair(scenechange, clip, mode=[16,16,1])
restore = core.rgvs.Repair(cleansed, clip, mode=[16,16,1])
corrected = core.vsrd.RestoreMotionBlocks(cleansed, restore, neighbour=clip, alternative=alt, gmthreshold=70, dist=1, dmode=2, noise=10, noisy=12, grey=0)
clip = core.rgvs.RemoveGrain(corrected, mode=[17,17,1])
clip.set_output()

Lastly, in my humble opinion I think RemoveDirt's namespace "vsrd" should be changed to "rdvs", making it familiar with RemoveGrain's "rgvs" namespace.

---

I wonder why Kassandro chose clense instead of cleanse? :confused:

[handaimaoh]

Yes, the calls should have been changed. My bad missing that. I'll look to see why it doesn't load. Last time I tested it it did.

[Mystery Keeper]

506k frames later and it still works. I don't think this method of testing will yield anything. I'll add logging of fatal errors and then let you try that build.
Sounds good. Thank you.
Update: got it crash faster while testing with vspipe. I think it said "fwrite error". Testing again with redirecting stderr to file.

[Mystery Keeper]

Ok, it has crashed with "fwrite() call failed" error while ran in windows console with output to stdout.
vspipe D:\Programming\TempLinearApproximate-VapourSynth\build\release-x32\test.vpy - -progress 2>E:\vsout.txt
Here's the log. (http://paste.org.ru/?4432tn)
It has not crashed for 1500 frames with stdout redirected to file (which wasn't intentional) before I've stopped it.
Used this script to give it harder time.

avisynth_plugins_path = 'E:\\avisynth-plugins\\'
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'

import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)

core.set_max_cache_size(2500)

import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
core.std.LoadPlugin(vapoursyth_plugins_path + filename)

core.avs.LoadPlugin(path = avisynth_plugins_path + 'mvtools2.dll')

core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x32\\templinearapproximate.dll')

d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'

ret = core.d2v.Source(input=d2vfile)

def pcToTv(input):
c = core.fmtc.resample (clip=input, css="444")
c = core.fmtc.matrix (clip=c, mats="601", matd="709")
c = core.fmtc.resample (clip=c, css="420")
c = core.fmtc.bitdepth (clip=c, bits=8)
return c

z = pcToTv(ret)

sys.path.append('D:\\Programming\\TempLinearApproximate-VapourSynth\\')
import MCDenoise

tlamc = MCDenoise.MCDenoise()
tlaArguments = dict(radius=5, BlockSize=8, Overlap=4, SubPel=4, SubPelInterp=2, Search=5, SearchParam=2, PelSearch=4, DCT=10, ThSAD=200)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = core.f3kdb.F3kdb(ret, dither_algo=2, grainy=0, grainc=0, keep_tv_range=True)

ret = pcToTv(ret)

ret.set_output()

def absdiff(x, y):
return min(max(0, 127 + x - y), 255)

unfiltered = core.text.Text(z, "unfiltered")
filtered = core.text.Text(ret, "filtered")
stack = core.std.StackHorizontal([unfiltered, filtered])
diffhist = core.std.Lut2([z, ret], function = absdiff)
#diffhist = core.generic.Levels(diffhist, planes=0, gamma = 3)
diffhist = core.text.Text(diffhist, "Difference")
filteredhist = core.generic.Levels(ret, planes=0, gamma = 2)
filteredhist = core.text.Text(filteredhist, "Filtered amplified")
diffstack = core.std.StackHorizontal([diffhist, filteredhist])
compare = core.std.StackVertical([stack, diffstack])
#compare.set_output()

[Mystery Keeper]

Actually, it might have been an unprintable character issue. Trying again with redirecting stdout to nul.