Vapoursynth

[Myrsloik]

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

Here's a slightly more verbose vspipe.exe (https://dl.dropboxusercontent.com/u/73468194/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]

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

[handaimaoh]

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.

[handaimaoh]

So fixed a few more bugs and now the new RemoveDirt dll is here (https://www.dropbox.com/s/hiupezbl5pahjtn/vsremovedirt.dll).

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:
http://s019.radikal.ru/i643/1311/56/8eb403e4b21c.png


Can this code (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/src/main.c?at=master#cl-382) be the case? Are there other activation reasons I need to handle? Or should I return something other than 0?

[Myrsloik]

Ok. Crashed again with vspipe. Error in console:
"No frame returned at the end of processing by TempLinearApproximate."
Also, this exception mesage:
http://s019.radikal.ru/i643/1311/56/8eb403e4b21c.png


Can this code (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/src/main.c?at=master#cl-382) 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]

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]

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]

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]

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 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-test1.exe). 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)

[lansing]

I don't see the 64bit option in the installer

[Mystery Keeper]

Tried to install. Got a block-screen from Windows Defender. It hanged, and now I can't get rid of it or close file manager from which I've run the installer. Windows 8.1 Pro, admin user.
Ended it with task manager. When running "as admin", it doesn't hang. The reason of blocking is "Unknown publisher". Proceeded with "Run anyway".

[Mystery Keeper]

"Failed to initialize VapourSynth environment".
Installed it when Python x32 was the active distribution. Made Python x64 active and reinstalled. It worked. But obviously, VapourSynth x32 wouldn't work after that.

[Myrsloik]

I don't see the 64bit option in the installer

You need to have the 64 bit version of python 3.3 installed for it to appear.

[Myrsloik]

"Failed to initialize VapourSynth environment".
Installed it when Python x32 was the active distribution. Made Python x64 active and reinstalled. It worked. But obviously, VapourSynth x32 wouldn't work after that.

Make active? There's no selection needed with the default installer. You simply install the 32 and 64 bit python to different directories and it will just work. That's how I did it on my computer.

[Mystery Keeper]

I'm using portable winpython (http://code.google.com/p/winpython/). Maybe that's the case.

[Myrsloik]

I'm using portable winpython (http://code.google.com/p/winpython/). Maybe that's the case.

Probably. I only test with the official binaries form python.org.

[Mystery Keeper]

Works, handles >9GB RAM load, loads in x64 VirtualDub. For proper testing need more plugins built for x64. Also, AvsPmod isn't working with x64 version, so we need a new editor. Though that can wait. Personally I'm waiting for the MVTools port the most. Thank you for your great work, Myrsloik!

[lansing]

I got the 64bit version installed, is there any 64bit source filter available right now so I can just load in a video?

[Mystery Keeper]

I got the 64bit version installed, is there any 64bit source filter available right now so I can just load in a video?FFMS2 (https://github.com/FFMS/ffms2/releases/download/2.19/ffms2-2.19.7z)

[lansing]

there's some issue with the installer, on the step "preparing to install" stage, it's telling me to close a lot of apps like WD rules, WD backup, homegroup provider etc, which should have nothing to do with vapoursynth.

[Myrsloik]

there's some issue with the installer, on the step "preparing to install" stage, it's telling me to close a lot of apps like WD rules, WD backup, homegroup provider etc, which should have nothing to do with vapoursynth.
It's because it installs the runtime dolls. Just tell it to not close anything and go on.

[lansing]

FFMS2 (https://github.com/FFMS/ffms2/releases/download/2.19/ffms2-2.19.7z)

where do you put the file?

I put the 64bit ffms2.dll and ffmsindex.exe into plugins64 folder, but it still said "no attribute with the name ffms2 exists".

src = core.ffms2.Source(r"sample.vob")


UPDATE:

I got it working. I need to write the load plugin line in the script to make it work, it doesn't auto load like the older version on 32bit filters.

[lansing]

running the 32bit vapoursynth gives a out of bounds memory crash in vd

[Mystery Keeper]

running the 32bit vapoursynth gives a out of bounds memory crash in vd
Post your script. Might be too complex. Also tell the specs of the source video.

Also, Myrsloik, some core plugins are not present in x64 distribution.

[lansing]

Post your script. Might be too complex. Also tell the specs of the source video.

Also, Myrsloik, some core plugins are not present in x64 distribution.

it's the same script i put up few posts above, just a ffms2 filter to load in a video. The source is a DVD vob.

The same script works on 64bit.


UPDATE:
I found out what's the problem, I installed the 64bit python on top of the 32bit python, should had install them on different directories.

http://stackoverflow.com/questions/10187072/how-do-i-install-python-2-7-3-32-bit-and-64-bit-on-windows-side-by-side

[handaimaoh]

So now that I've finished RemoveDirt port I was going to start on aWarpSharp2 and Sangnom2. Any other plugins anyone wants?

Also, I'll start a separate RemoveDirtVS thread and post some 32-bit and 64-bit dll builds in it.

[Mystery Keeper]

So now that I've finished RemoveDirt port I was going to start on aWarpSharp2 and Sangnom2. Any other plugins anyone wants?

Also, I'll start a separate RemoveDirtVS thread and post some 32-bit and 64-bit dll builds in it.

Great. Thank you!
Dfttest is rather needed.
Toon would be nice as part of anime anti-aliasing.
Some kind of autolevels/HDR plugin for when I need to amplify subtle differences in comparison.

[Reel.Deel]

So a little after a year VapourSynth is finally becoming more and more useful natively.
Thanks to all that are making it possible!:thanks:

@handaimaoh
Thanks for RDVS, hopefully I'll have some time tonight to tested thoroughly.

Regarding other plugins, for what is worth here's a list (http://forum.doom9.org/showthread.php?p=1650695#post1650695) of some that I think would be useful.

[Mystery Keeper]

Tried to use VIVTC in x64, and it didn't autoload. Had to load it manually.

[Mystery Keeper]

http://i047.radikal.ru/1311/b9/b25aa0d0912at.jpg (http://radikal.ru/fp/8a1dddb552944c76a98cda9719a7abdd)
As you see, near the end crash bug is still present. Here's the script:

vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'

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(16000)

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


core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x64\\templinearapproximate.dll')
core.std.LoadPlugin(path = 'C:\\Program Files (x86)\\VapourSynth\\core64\\plugins\\VIVTC.dll')

d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'
#d2vfile = 'F:\\Video to Process\\KOTOKO - Chercher\\KOTOKO - Chercher.d2v'

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

ret = core.vivtc.VFM(ret, order=1, mode=5)
ret = core.vivtc.VDecimate(ret)

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)

ret = pcToTv(ret)


ret.set_output()

[Myrsloik]

http://i047.radikal.ru/1311/b9/b25aa0d0912at.jpg (http://radikal.ru/fp/8a1dddb552944c76a98cda9719a7abdd)
As you see, near the end crash bug is still present. Here's the script:

vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'

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(16000)

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


core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x64\\templinearapproximate.dll')
core.std.LoadPlugin(path = 'C:\\Program Files (x86)\\VapourSynth\\core64\\plugins\\VIVTC.dll')

d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'
#d2vfile = 'F:\\Video to Process\\KOTOKO - Chercher\\KOTOKO - Chercher.d2v'

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

ret = core.vivtc.VFM(ret, order=1, mode=5)
ret = core.vivtc.VDecimate(ret)

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)

ret = pcToTv(ret)


ret.set_output()

Can't reproduce in the 32 bit version. Does it only crash in the 64 bit one?

[Mystery Keeper]

Having problems running x32 version with my portable python distributions. Might do something about it when I have more free time, but for now I'm limited to testing x64.

[Fullmetal Encoder]

So now that I've finished RemoveDirt port I was going to start on aWarpSharp2 and Sangnom2. Any other plugins anyone wants?

Also, I'll start a separate RemoveDirtVS thread and post some 32-bit and 64-bit dll builds in it.

I would have to vote for Dfttest myself. It's quite amazing.

[lansing]

I'm unable to load both the 64bit nnedi3 and bifrost dll

[Myrsloik]

Here's test2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-test2.exe).

It fixes plugin autoloading on x64 and prevents out of range frame requests in getFrameAsync (and getFrame) that I missed.

@Mystery Keeper
Can you cut the last 100 frames of the vob and upload it if it still crashes after cutting? I'm beginning to think this also depends on the source file itself.

[handaimaoh]

I would have to vote for Dfttest myself. It's quite amazing.

Ok, creating a repo for it as well.

[lansing]

plugin autoloading for x64 still doesn't work in test2

[Reel.Deel]

Ok, creating a repo for it as well.

What codebase are using for dfttest? The reason I asked it's because dfttest included in the Dither package includes various updates including 16-bit processing and support for additional planar colorspaces. If you already know this, sorry for being redundant.

[Mystery Keeper]

Some plugins present in x32 distribution are still not present in x64. Autoloading still not working. Script still crashes. Searching for a tool to cut a vob file now.