Vapoursynth

[Myrsloik]

Originally Posted by Mystery Keeper

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

Here's a slightly more verbose vspipe.exe. Note that you need to have the VS2013 runtime installed for it to work.

[Mystery Keeper]

Thank you. I'll test it overnight.

[kolak]

Originally Posted by Myrsloik

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.

Can try to get you access to 32 threads machine

Originally Posted by Reel.Deel

When I try to load RemoveDirt I get this error:

I figured out the error. I did a find and replace and that messed up the parameter string for the RemoveDirt functions which made the plugin instantiation crash. Committing the fix and I'll have a new binary posted shortly. I will also make the changes to the naming to be consistent with Vapoursynth RemoveGrain.

So fixed a few more bugs and now the new RemoveDirt dll is here.

Updated script to use RemoveDirt is:

clip = core.ffms2.Source(source='clippath')
cleansed = core.rgvs.Clense(clip)
sbegin = core.rgvs.ForwardClense(clip)
send = core.rgvs.BackwardClense(clip)
scenechange = core.rdvs.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.rdvs.RestoreMotionBlocks(cleansed, restore, neighbour=clip, alternative=alt, gmthreshold=70, dist=1, dmode=2, noise=10, noisy=12, grey=0)
clip = core.rgvs.RemoveGrain(clip, mode=[17,17,1])
clip.set_output()

Changed the namespace to use rdvs instead of vsrd. This does require the latest version of RemoveGrainVS to make sure you have all the Clense functions and the extra implemented modes.

[Octo-puss]

Noob question: Can this replace AviSynth? Or rather... can this replace AviSynth in MeGui?

[Mystery Keeper]

Ok. Crashed again with vspipe. Error in console:
"No frame returned at the end of processing by TempLinearApproximate."
Also, this exception mesage:



Can this code be the case? Are there other activation reasons I need to handle? Or should I return something other than 0?

[Myrsloik]

Originally Posted by Mystery Keeper

Ok. Crashed again with vspipe. Error in console:
"No frame returned at the end of processing by TempLinearApproximate."
Also, this exception mesage:



Can this code be the case? Are there other activation reasons I need to handle? Or should I return something other than 0?

This is very odd. I have no idea why this happens. Your code looks correct to me. Does this only happen after processing 100k+ frames for you?

[Mystery Keeper]

Tested with short clip. Crashed again.
"Frame: 8498/8585
FNo frame returned at the end of processing by TempLinearApproximate"

Removed one line of "ret = tlamc.TempLinearApproximate(ret, **tlaArguments)". Vspipe has processed the clip up to the same 8498th frame and hanged. Seems to be looped in something.
Trimmed to 50 frames, then to 200, then to 400. Processed alright in all three tests.
Trimmed to 50 frames and returned the second line. Crashed again.

Does not happen with raw TempLinearApproximate, even stacked 5 times. Something with the MC script?

[Mystery Keeper]

More weirdness. For this clip the crash always happens if I try to request one of the last 10 frames in the sequence that belong to the original D2V. If I trim it to 150 - it crashes on 140th. If I trim it to 250 - it crashes on 240th. Yes, I tried with different radius. And if I splice it with blank clip - it still crashes at 240th.

[Myrsloik]

Originally Posted by Mystery Keeper

More weirdness. For this clip the crash always happens if I try to request one of the last 10 frames in the sequence that belong to the original D2V. If I trim it to 150 - it crashes on 140th. If I trim it to 250 - it crashes on 240th. Yes, I tried with different radius. And if I splice it with blank clip - it still crashes at 240th.

I have a new theory. Which mvtools2 versions are you using? I do all my testing with the svp version.

[Mystery Keeper]

Oh, I lied. It crashes at the last 10 frames of the sequence double-processed by MC TLA. Splicing with blank clip does help. I just spliced in the wrong place in the script the last time.
I'm using the vanilla MVTools 2. Can't tell exactly which version.

[Myrsloik]

Originally Posted by Mystery Keeper

Oh, I lied. It crashes at the last 10 frames of the sequence double-processed by MC TLA. Splicing with blank clip does help. I just spliced in the wrong place in the script the last time.
I'm using the vanilla MVTools 2. Can't tell exactly which version.

Can you try with svp mvtools? I'm curious if it crashes as much with it.

[Mystery Keeper]

It does. Actually, it seems I have been using SVP version >_<
Just tried with original. Still crashes.

[Mystery Keeper]

More experiments with stacking tlamc.TempLinearApproximate and guarding with blank clip.
I append the blank clip before processing and trim it after processing, so blank frames are not being requested, but are participating in processing. Thus, they give a guarding margin.
There's a certain pattern to how many guard frames are needed for certain number of tlamc lines and certain radius.

2 lines: blank clip of 3 frames prevents the crash for any radius.
3 lines: 7 guard frames are needed for radius 1, 8 for 2, 9 for 3, 10 for 4, 11 for 5
4 lines: 11 for 1, 13 for 2, 15 for 3, 17 for 4, 19 for 5
5 lines: 15 for 1, 18 for 2, 21 for 3, 24 for 4, 27 for 5
6 lines: 19 for 1, 23 for 2, 27 for 3, 31 for 4, 35 for 5

[Myrsloik]

Originally Posted by Mystery Keeper

More experiments with stacking tlamc.TempLinearApproximate and guarding with blank clip.
I append the blank clip before processing and trim it after processing, so blank frames are not being requested, but are participating in processing. Thus, they give a guarding margin.
There's a certain pattern to how many guard frames are needed for certain number of tlamc lines and certain radius.

2 lines: blank clip of 3 frames prevents the crash for any radius.
3 lines: 7 guard frames are needed for radius 1, 8 for 2, 9 for 3, 10 for 4, 11 for 5
4 lines: 11 for 1, 13 for 2, 15 for 3, 17 for 4, 19 for 5
5 lines: 15 for 1, 18 for 2, 21 for 3, 24 for 4, 27 for 5
6 lines: 19 for 1, 23 for 2, 27 for 3, 31 for 4, 35 for 5

Apparently I made a change which hid the bug. Going back a version closer to r21 and I get your crash every time.

The simple reason is that TLA can't handle frame requests beyond the clip end, which vs filters are supposed to do by returning the last existing frame. For example requesting frame 502 in a clip with 500 frames is what kills it here every time. Add n = MIN(n, numFrames - 1) at the top and it'll work. I guess.

[Mystery Keeper]

Thank you. That fixed it. Though I must ask, why was TLA requested a frame beyond the end?

[Myrsloik]

Originally Posted by Mystery Keeper

Thank you. That fixed it. Though I must ask, why was TLA requested a frame beyond the end?

To simplify filter writing. It's a quirk of the api. If you get a request for a frame beyond the end you're supposed to return the last existing one.

I'm going to change it for r22, that's why I didn't notice all the crashes you were getting.

[Mystery Keeper]

Ok, now it HANGS unless I trim 3 frames from the end of the source clip. My guess is d2v.Source has got the same issue.

[Myrsloik]

Here's R22 test1. See if it crashes or does anything else odd.

The other major new is that the installer contains both 32 and 64 bit builds. Let the 64 bit revolution begin.

NO AVISYNTH PLUGINS CAN BE LOADED IN THE 64 BIT BUILDS. Not even the 64 bit ones. This will never change.

Changes:

vspipe now prints the fps as well
now arguments that are None in python aren't passed on to functions, this makes supplying defaults a lot easier
added core.version_number() so scripts can easily check for a supported core version
improved multithreaded locking, almost all functions in the vsscript and core API should be completely thread-safe now
Lut2, Merge and MaskedMerge functions changed, they now take two clip arguments named clipa and clipb instead of a 2 clip array, the old version is accepted as well for now, do vs.get_core(r21_arg_compat=False) to disable backward compatibility
minor API change, filters will no longer receive requests for frames beyond the end of a clip, instead the requested frame number is truncated, unknown length clip behavior is unchanged
simplified the vsscript api sample to use getFrame() and to be pure C code
added VS2013 projects
runtime registered formats now get automatically generated names so they're easier to identify
there should longer be "an exception happened when handling an exception" errors in python to keep the backtrace clearer
the python module now accepts any iterable as an array input
completely removed the Qt dependency on windows
added clense and the missing modes to removegrainvs
switched to C++11/C99 and VS2013, this means that both the VS2010 and VS2013 runtimes are both installed
added a port of vinverse (lachs0r)