single precision MVTools plugin (stable)

[feisty2]

@Are_
it seems the Linux header has already defined M_PI, fixed.
does it compile now?

[feisty2]

Nice. Only has a quick overview on the code.
The "auto"-count is shocking :)
I had to look up cpp documentation frequently for the used syntax elements.
I can see that probably because of the large - but hugely simplified - code base the used coding conventions are mixed (std::int32_t, int32_t, auto; reinterpret_cast vs traditional cast). Or is there an intentional difference on their usage?


I'd rewrite the whole thing from scratch and the coding style would be consistent, but it's too much work.
the copy-pasted code is c/c++98 style, code I wrote is script looking (as you said, lots of "auto"s)

edit:
I see a lot of macro constants here and there, it's bad practice even for C++98

[Are_]

Yup, now it compiles and works fine.

[feisty2]

Overlaps is still not 100% floating point, it still inherits the original code's two phase integer scaling 32 and 64 (32*64 is 2048 integer scale factor).
(Neither did I eliminate it completely in avs mvtools, I'm still using integer base (https://github.com/pinterf/mvtools/blob/mvtools-pfmod/Sources/overlap.h#L152) (lack of time) but there is no other intermediate scaling happens when dealing with float clips)

thx for the tip, I have made overlap9windows float. I started this thing so long ago and I have lost track of what needs to be rewritten as float. but I didn't remove the 2048 scaling cuz I dunno if that would lead to a bunch of hidden "gotcha"s. I have zero interest in spending days looking for bugs introduced by myself

[feisty2]

feature update:
- new parameter "thsad2" for mvsf.Degrain
- new parameter "thsad2" for mvsf.Compensate, only takes effect for compound output

"thsad2" enables cosine annealing along time dimension for MDegrain and MCompensate, I'm sure many of you have been longing for this feature from the avs MVTools, there you have it!

[feisty2]

is there any missing feature (that actually matters) still?
list them down below and I might be able to port them

[ChaosKing]

How hard would be 8-16 bit support to implement? For faster processing...
Btw have you checked if this issue is now gone in your rewrite? https://github.com/IFeelBloated/vapoursynth-mvtools-sf/issues/15

[feisty2]

How hard would be 8-16 bit support to implement? For faster processing...


extremely hard, I would basically have to rewrite the entire plugin from scratch to support integer inputs, it's too much work.



Btw have you checked if this issue is now gone in your rewrite? https://github.com/IFeelBloated/vapoursynth-mvtools-sf/issues/15

I dunno, I need more information to debug if the problem is still there.

[ChaosKing]

There is a script to try out https://forum.doom9.org/showthread.php?p=1840995#post1840995
It was only triggert if mvtools-sf was called from inside FrameEval().

[feisty2]

duh, can you build a binary and see for yourself if the problem still exists? it's just one command, very simple.
also, does the problem exist for the integer version mvtools?

[tormento]

can someone please build a binary for windows?
Please non AVX2 too.

[ChaosKing]

duh, can you build a binary and see for yourself if the problem still exists? it's just one command, very simple.
also, does the problem exist for the integer version mvtools?

The integer mvtools plugin does not have this problem.
I will try it in a linux vm later.

[ChaosKing]

I tried to compile it in msys2

g++ -shared -std=c++20 -lstdc++ -static -Ofast -Wno-subobject-linkage -o Filter.dll EntryPoint.cxx vapoursynth.lib libfftw3-3.lib

In file included from Include/Interface.hxx:3,
from EntryPoint.cxx:1:
Include/Buffer.hxx: In constructor 'Buffer<PixelType>::Buffer(auto:126, auto:127)':
Include/Buffer.hxx:14:51: error: 'aligned_alloc' is not a member of 'std'; did you mean 'aligned_union'?
14 | auto Origin = reinterpret_cast<PixelType*>(std::aligned_alloc(32, Stride * Height * sizeof(PixelType)));
| ^~~~~~~~~~~~~
| aligned_union

g++ --version
g++.exe (Rev2, Built by MSYS2 project) 10.1.0

Any idea what I'm missing?
I copied vsFilterScript inside the same folder, VS headers, created a libfftw3-3.lib

[feisty2]

std::aligned_alloc has been introduced to <cstdlib> since C++17, if msys2 cannot find it, there must be a bug in msys2 headers. you may drop the "std" namespace (change "std::aligned_alloc" to "aligned_alloc") as a temporary workaround

[ChaosKing]

Removed "std::". Now I have a bunch of undefined reference to `operator errors. Full log: https://pastebin.com/8EFGF4J1

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text+0x49cf): undefined reference to `operator delete(void*, unsigned long long)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text+0x4a4c): undefined reference to `operator delete(void*, unsigned long long)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text+0x4a60): undefined reference to `operator delete(void*, unsigned long long)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text+0x5562): undefined reference to `operator new(unsigned long long)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text+0x640b): undefined reference to `operator delete(void*, unsigned long long)'
...
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.xdata+0x41c): undefined reference to `__gxx_personality_seh0'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.xdata+0x460): more undefined references to `__gxx_personality_seh0' follow
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text$_ZN11MVExceptionD1Ev[_ZN11MVExceptionD1Ev]+0xb): undefined reference to `std::runtime_error::~runtime_error()'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text$_ZN11MVExceptionD0Ev[_ZN11MVExceptionD0Ev]+0x14): undefined reference to `std::runtime_error::~runtime_error()'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text$_ZN11MVExceptionD0Ev[_ZN11MVExceptionD0Ev]+0x27): undefined reference to `operator delete(void*, unsigned long long)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text$_ZN7DCTFFTWD0Ev[_ZN7DCTFFTWD0Ev]+0x43): undefined reference to `operator delete(void*, unsigned long long)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.xdata$_ZN7DCTFFTWD0Ev+0xc): undefined reference to `__gxx_personality_seh0'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text$_ZNSt7__cxx119to_stringEi[_ZNSt7__cxx119to_stringEi]+0x15d): undefined reference to `operator new(unsigned long long)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.text$_ZN15MVGroupOfFramesC1Eiiiiiiiii[_ZN15MVGroupOfFramesC1Eiiiiiiiii]+0x7e): undefined reference to `operator new[](unsigned long long)'
...
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.rdata$_ZTI7DCTFFTW[_ZTI7DCTFFTW]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.rdata$_ZTI11MVException[_ZTI11MVException]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\cc3XxJ5R.o:EntryPoint.cxx:(.rdata$_ZTV11MVException[_ZTV11MVException]+0x20): undefined reference to `std::runtime_error::what() const'
collect2.exe: error: ld returned 1 exit status

[feisty2]

I'm not sure what went wrong, it compiles in Cygwin and msys2 on my computer
I bet there's something fishy going on with your .lib files since it's the linker who's bitchin'

[ChaosKing]

Could you then upload your in msys2 compiled dll?
I updated my older msys2 installation via paman. Maybe there is an older package somewhere. Will try a new installation later.

[feisty2]

cumulative update:
- I merged every single bug fix from jackoneill's branch for the last 4 years.
- VectorStructure::sad has been promoted to double.

[feisty2]

The integer mvtools plugin does not have this problem.
I will try it in a linux vm later.

the problem might be gone now, I dunno, haven't tested it. I fixed some invalid use of uninitialized variables in the cumulative update.

[feisty2]

Could you then upload your in msys2 compiled dll?

there you go. (https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/r10_pre)
I take no responsibility for instant crash (some extended instruction sets like AVX2 or FMA might be missing on your machine), possible missing mingw64 dlls or any other binary related problem.

[feisty2]

Also could you consider using the normal include paths for vapoursynth and fftw3? The way things are now break packaging.

what do you mean by "normal include paths"?

[Are_]

Instead of:

#include "Include/fftw3.h"
#include "Include/VapourSynth.h"
#include "Include/VSHelper.h"

Do:
#include "fftw3.h"
#include "VapourSynth.h"
#include "VSHelper.h"

Else I have to patch them (source based distro).

[ChaosKing]

there you go. (https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/r10_pre)
I take no responsibility for instant crash (some extended instruction sets like AVX2 or FMA might be missing on your machine), possible missing mingw64 dlls or any other binary related problem.

Thx. Just checked my example script and the problem is still there.

Generate a very noisy clip and denoise it with mvtools. compare it inside and outside of FrameEval

def mvtoolsDenoise():
....


def abc(n, c):
return mvtoolsDenoise(c)

clip1 = clip.std.FrameEval(functools.partial(abc, c=clip))
clip2 = mvtoolsDenoise(clip)

Edit: Bad example, I will post a script later

[feisty2]

trivial update:
- the "limit" parameter of mvsf.Degrain now defaults to infinity. it still follows the [0.0, 1.0] range, however out-of-range samples are allowed for floating point clips, which makes infinity the only true "unlimited" bound.

[feisty2]

Thx. Just checked my example script and the problem is still there.

Generate a very noisy clip and denoise it with mvtools. compare it inside and outside of FrameEval

def mvtoolsDenoise():
....


def abc(n, c):
return mvtoolsDenoise(c)

clip1 = clip.std.FrameEval(functools.partial(abc, c=clip))
clip2 = mvtoolsDenoise(clip)

Edit: Bad example, I will post a script later

there was some major refactoring between v11 (https://github.com/dubhater/vapoursynth-mvtools/releases/tag/v11) and v12 (https://github.com/dubhater/vapoursynth-mvtools/releases/tag/v12) of jackoneill's branch, I started my branch from pre-v11 code base.

you can check if you are able to reproduce the problem with v11 of jackoneill's branch and if the problem disappears with v12

[ChaosKing]

I just found out that it happens with other filters as well. It was just easier to spot with mvtools-sf because I could use a very large temporal radius with strong denoising. Will post the problem in VS thread again.

[feisty2]

Instead of:

#include "Include/fftw3.h"
#include "Include/VapourSynth.h"
#include "Include/VSHelper.h"

Do:
#include "fftw3.h"
#include "VapourSynth.h"
#include "VSHelper.h"

Else I have to patch them (source based distro).

mvtools relies on vsFilterScript headers rely on VapourSynth.h -> VapourSynth.h must be placed in the "Include" folder

mvtools relies on VSHelper.h relies on VapourSynth.h -> VapourSynth.h must be placed in the mvtools folder

you will need 2 copies of VapourSynth.h, one in the "Include" folder and one in the mvtools folder, that doesn't look nice :confused:

[amichaelt]

mvtools relies on vsFilterScript headers rely on VapourSynth.h -> VapourSynth.h must be placed in the "Include" folder

mvtools relies on VSHelper.h relies on VapourSynth.h -> VapourSynth.h must be placed in the mvtools folder

you will need 2 copies of VapourSynth.h, one in the "Include" folder and one in the mvtools folder, that doesn't look nice :confused:

The whole point of doing it how _Are states is that it means one does't have to copy a bunch of headers around and simply can rely on GCC, etc. to find it in the includes/headers search paths (for example under /usr/include). Unless you have some need of a specific version of those headers, you really shouldn't be including them the way you are. Plenty of other plugins don't.

For example in jackoneill's mvtools you'll see the headers are done this way:

#include <limits.h>
#include <stdexcept>
#include <string>
#include <unordered_map>

#include <VapourSynth.h>
#include <VSHelper.h>

#include "Bullshit.h"
#include "CPU.h"
#include "Fakery.h"
#include "MVAnalysisData.h"
#include "MVDegrains.h"
#include "MVFrame.h"
#include "Overlap.h"

https://github.com/dubhater/vapoursynth-mvtools/blob/master/src/MVDegrains.cpp

This is the proper way you should be including the headers.

[Are_]

Yeah, exactly that.

You make your vsFilterScript install all the headers system wide somewhere like "/usr/include/vsFilterScript" and create pkg-config file for them.

Then you just retrieve the path for gcc with pkg-config and you don't need to worry about them.

This is good because it's easy to package and it's easy to use for everybody on their own projects.

I can send you PR on both projects with build system and edit project files for this (remove the "Include/" bits from them).

[feisty2]

Yeah, exactly that.

You make your vsFilterScript install all the headers system wide somewhere like "/usr/include/vsFilterScript" and create pkg-config file for them.

Then you just retrieve the path for gcc with pkg-config and you don't need to worry about them.

This is good because it's easy to package and it's easy to use for everybody on their own projects.

I can send you PR on both projects with build system and edit project files for this (remove the "Include/" bits from them).

done, I changed the extension of vsFilterScript headers to ".vxx" to avoid possible filename conflicts tho

[106062316]

I compiled mvsf using GCC 10.1 and mingw-w64

mvsf (https://www.mediafire.com/file/4eclnwwn03axqor/mvsf.7z/file)
mvsf-avx (https://www.mediafire.com/file/pyjit1are9hu8uh/mvsf-avx.7z/file)
mvsf-avx2 (https://www.mediafire.com/file/q6d3xcjsgp949yv/mvsf-avx2.7z/file)

[Pat357]

How did you compile it ?
I used the included Meson file and got :
Starting 64bit compilation of global tools
22:05:22 Running git update for vapoursynth-mvtools-sf...
22:05:24 + vapoursynth-mvtools-sf git ................................... [Recently updated]
The Meson build system
Version: 0.54.1
Source dir: H:/Mingw645/build/vapoursynth-mvtools-sf-git
Build dir: H:/Mingw645/build/vapoursynth-mvtools-sf-git/build
Build type: native build
Using 'PKG_CONFIG_PATH' from environment with value: 'H:\\Mingw645\\local64\\lib\\pkgconfig;H:\\Mingw645\\msys64\\mingw64\\lib\\pkgconfig'
Using 'PKG_CONFIG_PATH' from environment with value: 'H:\\Mingw645\\local64\\lib\\pkgconfig;H:\\Mingw645\\msys64\\mingw64\\lib\\pkgconfig'
Project name: vapoursynth-mvtools-sf
Project version: 10
Using 'CXX' from environment with value: 'ccache g++'
Using 'CXXFLAGS' from environment with value: '-mthreads -mtune=native -O2 -pipe'
Using 'LDFLAGS' from environment with value: '-pipe -static-libgcc -static-libstdc++'
Using 'CPPFLAGS' from environment with value: '-D_FORTIFY_SOURCE=0 -D__USE_MINGW_ANSI_STDIO=1'
Using 'CXX' from environment with value: 'ccache g++'
Using 'CXXFLAGS' from environment with value: '-mthreads -mtune=native -O2 -pipe'
Using 'LDFLAGS' from environment with value: '-pipe -static-libgcc -static-libstdc++'
Using 'CPPFLAGS' from environment with value: '-D_FORTIFY_SOURCE=0 -D__USE_MINGW_ANSI_STDIO=1'
C++ compiler for the host machine: ccache g++ (gcc 10.1.0 "g++ (Rev2, Built by MSYS2 project) 10.1.0")
C++ linker for the host machine: g++ ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64
Using 'PKG_CONFIG' from environment with value: 'H:/Mingw645/msys64/mingw64/bin/pkg-config --static'
Found pkg-config: --static (0.29.2)
Using 'PKG_CONFIG_PATH' from environment with value: 'H:\\Mingw645\\local64\\lib\\pkgconfig;H:\\Mingw645\\msys64\\mingw64\\lib\\pkgconfig'
Run-time dependency vapoursynth found: YES 50
Using 'PKG_CONFIG_PATH' from environment with value: 'H:\\Mingw645\\local64\\lib\\pkgconfig;H:\\Mingw645\\msys64\\mingw64\\lib\\pkgconfig'
Run-time dependency vsfilterscript found: YES 50
Using 'PKG_CONFIG_PATH' from environment with value: 'H:\\Mingw645\\local64\\lib\\pkgconfig;H:\\Mingw645\\msys64\\mingw64\\lib\\pkgconfig'
Run-time dependency fftw3 found: YES 3.3.8
Build targets in project: 1

Found ninja.EXE-1.10.0 at H:\Mingw645\msys64\mingw64\bin/ninja.EXE
ninja: Entering directory `build'
[1/2] Compiling C++ object vapoursynth-mvtools-sf@sha/src_EntryPoint.cxx.obj
FAILED: vapoursynth-mvtools-sf@sha/src_EntryPoint.cxx.obj
ccache g++ @vapoursynth-mvtools-sf@sha/src_EntryPoint.cxx.obj.rsp
../src/EntryPoint.cxx:1:10: fatal error: Interface.vxx: No such file or directory
1 | #include "Interface.vxx"
| ^~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
22:05:27 + Running rustup_update...
It seems I'm missing some files... are these available from your other repo''s ?
What am I doing wrong ?

[Are_]

You need to install https://github.com/IFeelBloated/vsFilterScript too.

Your log says:
Run-time dependency vsfilterscript found: YES 50
But that has to be wrong, it should say:
Run-time dependency vsfilterscript found: YES 1

[Pat357]

Thanks for your input, so I got vsfilterscript from repo and installed it first.
Now I got :

https://github.com/IFeelBloated/vsFilterScript/issues/3

I reported it with the vsfilterScript because The breaking error seems to be:
include/vsFilterScript/Buffer.vxx:14:51: error: 'aligned_alloc' is not a member of 'std'; did you mean 'aligned_union'?

Any ideas ?

Edit : I think I found the issue on hand here : because Mingw64and even MSVC don't support aligned_alloc, it looks like is simply impossible to compile the current code with Mingw64 gcc / g++.
See also https://github.com/IFeelBloated/vapoursynth-mvtools-sf/issues/17.
The author stated he will not alter his code for this.

That's really a pity.
So atm there would be no compiler on a Windows system able to compile the current code.
This would be a major issue for a lot of people.

How 106062316 managed to get the code compiled on Mingw is beyond me.

[feisty2]

there’re pre-built binaries at #132, and you can simply drop the std namespace (change std::aligned_alloc to aligned_alloc) to make it work for mingw

[feisty2]

How 106062316 managed to get the code compiled on Mingw is beyond me.

???? Is removing 5 characters ( std:: ) that much of a challenge?

[Pat357]

there’re pre-built binaries at #132, and you can simply drop the std namespace (change std::aligned_alloc to aligned_alloc) to make it work for mingw


I'm not a developer and I didn't know the workaround is so simple.
Thank you very much for this hint.

Got it all working now !

[ChaosKing]

I just tried this example here: (https://forum.doom9.org/showthread.php?p=1911978#post1911978)

#MDegrainN
sup = core.mvsf.Super(clip)
vec = core.mvsf.Analyze(sup, radius=1, overlap=4)
vec = core.mvsf.Recalculate(sup, vec, blksize=4, overlap=2)
clip = core.mvsf.Degrain(clip, sup, vec, thsad=400)

With radius = 1 it just shows a green frame.

EDIT
I used the "r10_pre" binary from github.

[Quadratic]

I just tried this example here: (https://forum.doom9.org/showthread.php?p=1911978#post1911978)

#MDegrainN
sup = core.mvsf.Super(clip)
vec = core.mvsf.Analyze(sup, radius=6, overlap=4)
vec = core.mvsf.Recalculate(sup, vec, blksize=4, overlap=2)
clip = core.mvsf.Degrain(clip, sup, vec, thsad=400)

With radius = 1 it just shows a green frame.

I am not seeing this with a fresh compile from git on Arch.

[ChaosKing]

You also changed radius to 1?

The compiled binary from here has the same issue, but the frame is black now xD https://forum.doom9.org/showthread.php?p=1912769#post1912769

[Quadratic]

Yes, no problems.

import vapoursynth as vs
import vsutil
core = vs.core

clip = core.lsmas.LWLibavSource()
clip = vsutil.depth(clip, 32)
clip = core.grain.Add(clip, var=10, uvar=3, seed=444)
ref = clip

sup = core.mvsf.Super(clip)
vec = core.mvsf.Analyze(sup, radius=1, overlap=4)
vec = core.mvsf.Recalculate(sup, vec, blksize=4, overlap=2)
clip = core.mvsf.Degrain(clip, sup, vec, thsad=400)

ref.set_output(1)
clip.set_output(2)

[poisondeathray]

Last commit was Aug 18,2020 "various bug fixes "
https://github.com/IFeelBloated/vapoursynth-mvtools-sf/commit/38dadba1ef853a90fab51aa886c455587173630b

CK your binary from post 131 predates that commit (May 20,2020)

[ChaosKing]

Can we have a bug fix release then? :D

[poisondeathray]

Can we have a bug fix reelase then? :D

I was going to ask the same thing :D

[feisty2]

you need a binary compiled after this: https://github.com/IFeelBloated/vapoursynth-mvtools-sf/commit/38dadba1ef853a90fab51aa886c455587173630b#diff-bcabb6b4f84e2f0493deb9b5f9e353c9a64e396d8f24f63f52569603bb85bb2e

[MysteryX]

When I try to load libmvtools_sf_em64t.dll, it gives this error, why?


Avisynth open failure:
Python exception: Failed to load libmvtools_sf_em64t.dll. GetLastError() returned 126. The file you tried to load or one of its dependencies is probably missing.

[ChaosKing]

Dependencies are:
- msvcrt.dll
- libfftw3-3.dll

[MysteryX]

OK installed libfftw3-3 and it loads.

If I load r9, Degrain doesn't exist. If I load r10 pre-release, it says that Analyse doesn't exist

mvsf.Analyse is removed, type "Analyze" instead
How do I reference Analyse? ah dang -- change 's' with 'z'

Now Degrain has too many unnamed arguments specified.


clean = core.mvsf.Degrain(c if chroma else cy, super2, bvec1, fvec1, bvec2, fvec2, bvec3, fvec3, bvec4, fvec4, thsad=thSAD)


The complete lack of documentation is a bit frustrating.

[MysteryX]

xClean will support r9 of mvtools-sf and not r10-prerelease. This is meant to be a swap-in replacement for the regular library. Adding new API features is fine, but removing features and changing names, that's not good, because it breaks API compatibility.

This will also cause serious versioning issues. Some scripts will be written for mvtools-sf r9 and some for mvtools-sf r10. For a program like StaxRip, which of the 2 versions should it bundle then? Backwards compatibility is important.

[StainlessS]

Could implement both Analyse and Analyze, and avoid confusion/breakage [as for GreyScale/GrayScale in Avisynth].