Vapoursynth

[mastrboy]

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.

Any chance to get a port of Tcomb? (http://bengal.missouri.edu/~kes25c/TCombv2B2.zip)

[Myrsloik]

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.

Let me end your search: dgindex

Also, why so surprised that they aren't there? It's not like anyone said anything to imply they would be.

AND KEEP THIS FROM TURNING INTO A "REQUEST PLUGIN PORTS AND DON'T READ THE LAST POST THREAD"

[handaimaoh]

Any chance to get a port of Tcomb? (http://bengal.missouri.edu/~kes25c/TCombv2B2.zip)

Sure, it'll have to wait for other work to be done though.

[Mystery Keeper]

Here's the end of the video that leads to crash. (http://www.mediafire.com/?34e84dlmb707chd)
Also, tried with two other videos. No crash. So you might be right about source being the case.

[Mystery Keeper]

Let me end your search: dgindexYup. Already figured it out.

Also, why so surprised that they aren't there? It's not like anyone said anything to imply they would be.Because they are in x32 distribution. The difference in distributions is confusing.

AND KEEP THIS FROM TURNING INTO A "REQUEST PLUGIN PORTS AND DON'T READ THE LAST POST THREAD"Who? Me? I'd never do such thing ^_^

[Mystery Keeper]

Sharing a plugin loading snippet. Doesn't let load errors stop your script. Prints errors in vspipe. Does nothing in VirtualDub.

from __future__ import print_function
#This line must be in the beginning

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)

#Loading all plugins in path. On error - print and continue.
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
except Exception as e:
print("Error: ", e, end='\n', file=sys.stderr)

[Myrsloik]

Sharing a plugin loading snippet. Prints errors in vspipe. Does nothing in VirtualDub.

from __future__ import print_function
#This line must be in the beginning

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)

#Loading all plugins in path. On error - print and continue.
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
except Exception as e:
print("Error: ", e, end='\n', file=sys.stderr)

So? You have no console, hence no stderr, when running an application with windows. If you compile a vdub with a console window you'll see the printed errors just fine.

[Mystery Keeper]

I mean it is good it does nothing in VirtualDub. Like not raising any errors and just letting you encode. That wasn't a question post. Just sharing a snippet ^_^

[Mystery Keeper]

By the way, Myrsloik, I'm thinking about writing an editor for VapourSynth scripts in Qt. But there's something I don't quite understand now. What is the right way to present the output frame to user? Especially if it is high bit depth.

[Myrsloik]

By the way, Myrsloik, I'm thinking about writing an editor for VapourSynth scripts in Qt. But there's something I don't quite understand now. What is the right way to present the output frame to user? Especially if it is high bit depth.

Convert everything to 24bit RGB at high quality settings? It will end up converted to it sooner or later in the display process anyway*. (assuming you don't have a very expensive monitor and all that other asterisk stuff here)

[Mystery Keeper]

Hmm. I was thinking about using some existing libs. But I guess I can just reuse fmtconv code for it.

[sl1pkn07]

By the way, Myrsloik, I'm thinking about writing an editor for VapourSynth scripts in Qt. But there's something I don't quite understand now. What is the right way to present the output frame to user? Especially if it is high bit depth.

https://github.com/dubhater/vapoursynth-viewer

[Mystery Keeper]

Oh, awesome.

[Joachim Buambeki]

...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).
...
A similar suport for After Effects would be great but that would mean that a separate plugin would have to be written, since AE isn't OpenFX compatible unfortunately.

Is this something you would consider Myrsloik?

[Myrsloik]

Is this something you would consider Myrsloik?

You description is still so vague I'm not even certain what you want me to do. I can however say that it probably won't happen unless there's money involved. Those enterprise apis are just too annoying for me to want to deal with in my spare time.

I'm also curious how a command line could be integrated into any application like that. Sounds like it would be an ugly hack if it was done.

[Myrsloik]

I just brought an i7 4470k and ran some speed test comparison between avisynth mt on the d2v source filter and tivtc/vivtc.

source was a 720x480 anime, all benchmark were measured by avsmeter.


avisynth-mt(fps)/cpu% vapoursynth(fps)/cpu%

d2v (mode 5)308/12% 912/12%
tfm (mode 2)215/17% 330/12%
tfm+tdecimate (mode 5)157/12% 255/12%
vfm 253/12%
vfm+vdecimate 31/13%




With vapoursynth, cpu was never fully utilized, not even 30%. And there's definitely something wrong with vdecimate, as running it alone also gives me 60fps.

I can't reproduce your results. To me all filters appear to perform similarly.

[lansing]

I can't reproduce your results. To me all filters appear to perform similarly.

that benchmark was did on R21, they are running correctly in R22-test2 now.


Filters Vapoursynth 32bit/CPU% Vapoursynth 64bit/CPU%
d2v + VIVTC 202/17% 213/17%
ffms2 + VIVTC 266/23% 310/23%


This benchmark was based on the same 720x480 source before, running 10k frames with vspipe output to null.
Running ffms2 as the source filter was significantly faster than d2v.
The d2v+vivtc combination was 25% faster than d2v+tivtc in avisynth mt, while ffms2+tivtc also gave around 300fps comparing to ffms2+vivtc.

[Mystery Keeper]

Tried opening Riaru Onigokko 2 movie VOB with FFMS2 isntead of d2v. Didn't crash near the end, but some frames were obviously misplaced, making the movie jerky.

[Joachim Buambeki]

You description is still so vague I'm not even certain what you want me to do. I can however say that it probably won't happen unless there's money involved. Those enterprise apis are just too annoying for me to want to deal with in my spare time.

I'm also curious how a command line could be integrated into any application like that. Sounds like it would be an ugly hack if it was done.

I am just a user, so I cannot tell how it would be implemented best. It would be just a pity to see all those great filters available for Avi-/Vapoursynth not available in professional applications, from what I've learned so far, alot of them are at least on par with professional PlugIns.

I guess it is a chicken egg/problem.
As a amateur coming from Avisynth currently progressing to professional tools (meaning easy to use for idiots if you can pay for it, not necessarily always because of professional quality) I can only make assumptions that something like a proper implementation of open source filters would be highly welcome by alot of pros and there may be a market for you. Of course those people will only pay/donate once there is something that shows potential by beeing usable at least on a basic level.

I can only throw in ideas, do your research on that topic and decide if it is worth the time for you. My previous posts shuld be a starting point what to look for.

Cheers
JB

[Adub]

Myrsloik,

I'm looking at performing a merge to renew my CUDA work to bring it up to date with the latest Vapoursynth mainline. I noticed that a large amount of the core has been refactored/regrouped recently, which is fine. The one thing I wonder about is if this is looking to be the "final" version of the core organization, or should I expect another reorganization soon? I ask, because I'd rather not start the merge work if I'm just going to have to do another large merge sometime soon.

I'm mostly talking about the standard filters extraction, along with a few other edits.

[Myrsloik]

Myrsloik,

I'm looking at performing a merge to renew my CUDA work to bring it up to date with the latest Vapoursynth mainline. I noticed that a large amount of the core has been refactored/regrouped recently, which is fine. The one thing I wonder about is if this is looking to be the "final" version of the core organization, or should I expect another reorganization soon? I ask, because I'd rather not start the merge work if I'm just going to have to do another large merge sometime soon.

I'm mostly talking about the standard filters extraction, along with a few other edits.

All big changes are done. There are only small fixes left on my to do list now. There's the last phase of the qt removal coming tomorrow or so but that's it.

I'm curious, how did you add cuda support? Do you keep two processing queues? One for cuda and one for cpu?

[Adub]

Essentially yes.

The memory usages of the CPU and GPU are tracked separately, and there is a frame level indicator identifying on which device the frame resides.

That way we can mix CPU filters with GPU filters, and optimize filter placement.

I added a core filter I call TransferFrame for moving data back and force between the CPU and GPU. This significantly simplifies the filter code, as they just ignore memory transfers, and optimizes performance by minimizing data transfer between devices.

TransferFrame lets me dictate when to transfer data and when to send it back, letting me "batch" filters accordingly.

All of this works, and I demoed it for my Masters Thesis defense, with a strong handful of the core filters being ported.

I wanted to add multi-GPU support but I didn't have time, but all GPU processing is completely asynchronous (took me a bit to get that right), meaning that it will see speed increases as scheduling hardware gets better on Nvidia's GPUs (I'm going to try and get my hands on a 780 Ti in a few months for future research).

It's a bit out of date with the current core, and still runs pre-vspipe, so I have some work to do with my test scripts and overall code base to bring it back in line. Not to mention CUDA 5.5 support, and handling the C++11 upgrades.

I wrote it with plugin developers in mind, so that they can easily add CUDA capable versions of their own plugins. Granted, I don't know how this will work with the latest core, so I'll need to dive into that as well.

[Myrsloik]

It's update time!

Have fun with R22 test 3 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-test3.exe). It should be very close to the actual release now that almost all filters have x64 compiles ready. Just wanted to wait a bit for the plugin writers to keep up.

Changes since test 2:

Really fixed the autoloading, I mean it
A custom debug message handler can be set from python as well now
The MakeDiff and MergeDiff functions were added (mt_makediff/mt_adddiff)
The installer should no longer complain about files being in use unless it's really necessary
Chikuzen's generic filters plugin is included
Avisource for x64 is included



Known issues:
Still missing x64 compile of assvapour

[Mystery Keeper]

Thank you for a great release!
-Confirming autoloading working.
-Windows SmartScreen still blocks the installer due to "Unknown publisher".
-Still getting that crash with that particular video and d2vsource. This time I saved the crash report. (http://paste.org.ru/?esc0vc)

[Mystery Keeper]

Fiddled with Python paths in registry. Now my script opens fine by VirtualDub, but vspipe only outputs the plugins path and then crashes.

Added these keys in registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.3\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.3\PythonPath

What is the way VapourSynth searches for Python distributions? How can I make it recognize my multiple portable distributions?

Also, here's an improved plugins load snippet for people (like me) unfamiliar with Python:

from __future__ import print_function
#put that in the beginning of script

import sys
sys.path.append('E:\\vapoursynth-plugins\\py\\')
import platform
architecture = platform.architecture()
if architecture[0] == '64bit':
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
else:
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'
print('Plugins folder: ', vapoursynth_plugins_path, end='\n', file=sys.stderr)
import os
for filename in os.listdir(vapoursynth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursynth_plugins_path + filename)
except Exception as e:
print('Error: ', e, end='\n', file=sys.stderr)

edit: Forgot to mention: I uninstalled and reinstalled VS after these changes.

[Myrsloik]

Fiddled with Python paths in registry. Now my script opens fine by VirtualDub, but vspipe only outputs the plugins path and then crashes.

Added these keys in registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.3\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.3\PythonPath

What is the way VapourSynth searches for Python distributions? How can I make it recognize my multiple portable distributions?

Also, here's an improved plugins load snippet for people (like me) unfamiliar with Python:

from __future__ import print_function
#put that in the beginning of script

import sys
sys.path.append('E:\\vapoursynth-plugins\\py\\')
import platform
architecture = platform.architecture()
if architecture[0] == '64bit':
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
else:
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'
print('Plugins folder: ', vapoursynth_plugins_path, end='\n', file=sys.stderr)
import os
for filename in os.listdir(vapoursynth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursynth_plugins_path + filename)
except Exception as e:
print('Error: ', e, end='\n', file=sys.stderr)

edit: Forgot to mention: I uninstalled and reinstalled VS after these changes.

You only need the registry entries to trick the installer. VapourSynth itself is simply statically linked with python33.dll (i think that's the name) so as long as the relevant python dll can be found in the path it should work.

The rest is handled by python.

[Mystery Keeper]

Ok. I figured it out. Had to read your installer script for that. HKCU\SOFTWARE is shared for x32 and x64 applications, while HKLM\SOFTWARE is redirected. Read this. (http://msdn.microsoft.com/en-us/library/aa384253%28v=VS.85%29.aspx) I already had Python keys in HKCU, but created them manually in HKLM. That's why VS x32 wouldn't install for me - it already received the same key from HKCU for both x32 and x64. My keys were also wrong. So I moved the correct keys from HKCU to HKLM and created correct copies in Wow6432Node. Then installed VS again. It installed properly. Vspipe x32 works fine, but x64 still crashes.

You need to improve your installer logic somehow. I see it like this: when on x64, check HKLM first. If both keys are present - you can install both x32 and x64 VS. If that fails - check HKCU and only install one version. I don't know how to determine which one though.

edit: I think the safest logic would be this:
-Check HKCU key.
-If it is present - determine, which Python version it points to and install the corresponding VS version.
-Check HKLM keys for those versions that were not found in HKCU. Meaning one or both - you won't find the keys for both versions in HKCU.
-If present - check if they point to correct Python versions and install corresponding VS versions.

[Myrsloik]

Ok. I figured it out. Had to read your installer script for that. HKCU\SOFTWARE is shared for x32 and x64 applications, while HKLM\SOFTWARE is redirected. Read this. (http://msdn.microsoft.com/en-us/library/aa384253%28v=VS.85%29.aspx) I already had Python keys in HKCU, but created them manually in HKLM. That's why VS x32 wouldn't install for me - it already received the same key from HKCU for both x32 and x64. My keys were also wrong. So I moved the correct keys from HKCU to HKLM and created correct copies in Wow6432Node. Then installed VS again. It installed properly. Vspipe x32 works fine, but x64 still crashes.

You need to improve your installer logic somehow. I see it like this: when on x64, check HKLM first. If both keys are present - you can install both x32 and x64 VS. If that fails - check HKCU and only install one version. I don't know how to determine which one though.

Improve what? I support the official python distribution. If you want to play around with custom junk you're free to do so. The crashes you mention are most likely related to you not being able to put all needed python an vapoursynth dlls where they can be found.

[Mystery Keeper]

Oh. And now vspipe x64 printed "Frame returned not of the declared type" before crashing. VirtualDub still works perfectly fine.

Why so hostile? I'm sincerely trying to help by testing and suggesting improvements. I really appreciate your hard work.

[Mystery Keeper]

Played with my script. The source of crashes is core.std.MakeDiff.

[Myrsloik]

Oh. And now vspipe x64 printed "Frame returned not of the declared type" before crashing. VirtualDub still works perfectly fine.

Why so hostile? I'm sincerely trying to help by testing and suggesting improvements. I really appreciate your hard work.

Because it's a pointless problem to solve. I may as well put up an archive of all the files in the installer or make it possible to manually select the python install path(s). That would make more sense even for your odd portable case.

Anyway, I'll test makediff and see what happens...

[Myrsloik]

Played with my script. The source of crashes is core.std.MakeDiff.

Can't reproduce it. I used this script:

import vapoursynth as vs

core = vs.get_core()

clip = core.avisource.AVISource('a downloaded file.avi')
blur_clip = core.generic.Blur(clip, planes=0)
diff_clip = core.std.MakeDiff(clip, blur_clip, planes=0)
sharpened_clip = core.std.MergeDiff(clip, diff_clip, planes=0)
sharpened_clip.set_output()

[Mystery Keeper]

Tried your script, only with ffms2. The same result:
-perfectly fine with vspipe x32
-perfectly fine with VirtualDub x64
-crash with vspipe x64

Went as far as completely reinstalling all Python 3.3 distributions and VapourSynth. Still the same.

[Are_]

I'm able to reproduce this with some videos only when using ffms2 as source filter (linux.x86_64).

Investigating a little it looks like generic.Blur corrupts the frames (not sure why, how), and once this happens, if you pass this frames to std.MakeDiff it crashes vspipe (it also crashes vsviewer).
import vapoursynth as vs

core = vs.get_core()

clip = core.ffms2.Source('[some] random - 07 [file].mkv')
blur_clip = core.generic.Blur(clip, planes=0)
#diff_clip = core.std.MakeDiff(clip, blur_clip, planes=0)
diff_clip = blur_clip
sharpened_clip = core.std.MergeDiff(clip, diff_clip, planes=0)
sharpened_clip.set_output()
A corrupted frame. (http://i.imgur.com/wdqiedR.png)

But I'm not sure if its ffms2's fault, genericfilters's fault, or my hardware. :/

[Mystery Keeper]

For me it doesn't crash my 64-bit build of vsviewer. Though I modified it to compile with Qt5. Shouldn't make any difference. Also, no corrupted frames.
64-bit vspipe crashes regardless of the source, even if I replace Blur with BlankClip. Both MakeDiff and MergeDiff lead to crash. And the crash always happens right in the beginning.

[Myrsloik]

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

Changes from test 3:

Generic filters not included at the moment since there probably are some bugs in it
Fixes reference leaks in some filters when a frame error occurs
The resize filter reports more errors immediately on instantiation
Sorting in list_functions()


Still looking at the crashiness created by generic filters and maybe makediff. Will probably be a few more days until I have time to investigate it thoroughly.

[Myrsloik]

Here's an x64 compile of genericfilters (https://dl.dropboxusercontent.com/u/73468194/GenericFilters.dll).

It fixes an access violation in the sse2 optimized 9/10 bit 3x3 convolution. If there still are any crahes at all remaining in VapourSynth it'd be helpful if you report them again.

[Mystery Keeper]

The same. 64-bit vspipe crashes on MakeDiff/MergeDiff. Now with error message.
http://s020.radikal.ru/i721/1312/c7/7fe84e517535.png

Edit: And I remind, the crash does NOT happen in 64-bit VirtualDub.

[Myrsloik]

The same. 64-bit vspipe crashes on MakeDiff/MergeDiff. Now with error message.
http://s020.radikal.ru/i721/1312/c7/7fe84e517535.png

Edit: And I remind, the crash does NOT happen in 64-bit VirtualDub.

Tried it again. It still works here in vspipe. I even tried YUV420P8/10/16 in valgrind and didn't see anything relevant. I simply can't reproduce it.

Any kind of debugging info would help or would it be possible for me to remotely control your computer for a few minutes?

[Mystery Keeper]

WunDBG output. (http://paste.org.ru/?sn3mwk)

http://s018.radikal.ru/i522/1312/fc/f1c97e611f48.png

[Myrsloik]

Find me on irc. I'm in #darkhold on Rizon and some other avisynth channels. This won't be solved without faster communication.

[absence]

Is the CUDA work general enough that OpenCL can be added as well? Hopefully CUDA and OpenCL can share common logic for handling filter placement, transfers to/from GPU, etc. even if the APIs are different.

[Myrsloik]

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

After a long debugging session with mystery keeper a very rare asm bug on x64 windows has been fixed.
The installer will now refuse to install when the python installations are a mess.
Generic filters has been added again after finding the crash issue in the code.

This will most likely become the final released version.

[lansing]

I tried to run a vpy script in vsfs mode, the script has loaded mvtools2 from avs, and when I try to mount it, it returned an error.

Python exception: No attribute with the name avs exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1148, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:17833)
File "F:\source\1993.vpy", line 12, in <module>
core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
File "vapoursynth.pyx", line 789, in vapoursynth.Core.__getattr__ (src\cython\vapoursynth.c:12729)
vapoursynth.Error: No attribute with the name avs exists. Did you mistype a plugin namespace?

[Myrsloik]

I tried to run a vpy script in vsfs mode, the script has loaded mvtools2 from avs, and when I try to mount it, it returned an error.

Python exception: No attribute with the name avs exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1148, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:17833)
File "F:\source\1993.vpy", line 12, in <module>
core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
File "vapoursynth.pyx", line 789, in vapoursynth.Core.__getattr__ (src\cython\vapoursynth.c:12729)
vapoursynth.Error: No attribute with the name avs exists. Did you mistype a plugin namespace?


VSFS uses the x64 version by default and avisynth compatibility can't work there. You have to unregister the x64 vsfs handler and register the 32 bit one instead to do what you want.

[lansing]

VSFS uses the x64 version by default and avisynth compatibility can't work there. You have to unregister the x64 vsfs handler and register the 32 bit one instead to do what you want.

Got it working thanks.

[Myrsloik]

R22 released. Download links on the website as usual and the changelog is in the first post.

Don't forget to read the notes in the release blog post (http://www.vapoursynth.com/2013/12/r22-the-number-of-bits-shall-be-64/) about compatibility. Lut2, Merge and MaskedMerge got the arguments changed.

Have fun with the 64 bits in windows.

[sneaker_ger]

The following script does crash, not sure if l-smash's or vs' fault:
import vapoursynth as vs
core = vs.get_core()

ret = core.lsmas.LWLibavSource(source='park_joy_1080p50.y4m')

ret.set_output()
http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m

[Myrsloik]

The following script does crash, not sure if l-smash's or vs' fault:
import vapoursynth as vs
core = vs.get_core()

ret = core.lsmas.LWLibavSource(source='park_joy_1080p50.y4m')

ret.set_output()
http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m

Try it with other files and see if it works. Preferably one that's worked before.

[sneaker_ger]

Crashes with other y4m files as well, not with e.g. mov files. So I guess it's l-smash's fault?

Any other source filter for y4m?