single precision MVTools plugin (stable)

[feisty2]

binary (x64 for winnt):https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/r10_pre

source code: https://github.com/IFeelBloated/MVTools_SF/tree/master

I'm feeling super duper awesometastic cuz, yeah, I'm insane enough to learn C++ by hacking this big fat monster plugin :)

namespace: mvsf.xxx

anyways, a few things I gotta say here:
1. currently available functions: Super, Analyze, Recalculate, Compensate and Degrain1/2/3, didn't add flow functions yet cuz I got some doubts about truemotion
2. SAD, SCD stuff are floats now (default: thSAD=400.0 (200.0 for Recalculate and 10000.0 for Compensate), thSCD1=400.0, thSCD2=130.0)
3. "limit" in Degrain is float now, and with a range of 0.0 - 1.0, 0.0=no filtering, 1.0=no limit
4. "isse" is removed cuz, well, I mean over 80% of the sse code won't even work on uint16_t clips...
5. I ain't figured out how the hell that dct stuff actually works, so please don't use it (keep dct=0) for now
6. "Analyse" got a new name now! and it's called "Analyze" :D , I'm American and "analyse" always gets autocorrected and that's not nice, now it's "Analyze" so good news to Americans and Canadians, but the old "Analyse" still works for compatibility reasons and British blokes ;) , so you got the freedom to choose "mvsf.Analyze" or "mvsf.Analyse" and both will work

EDIT:
test2
1. Added SATD support (dct=5 works now)
2. Added mvsf.Finest (flow functions will be ready soon)

EDIT2:
test3
1. Fixed possible overflow in SATD
2. Removed SATD for 8x4 16x8 8x16 blocks, no one uses them anyways
3. Added SATD support to 32x32 blocks
4. SATD for 16x16 blocks is corrupted in the original vaporsynth port, fixed now

EDIT3:
test4
1. Added mvsf.FlowBlur (you got a full floating point QTGMC now, if you want to)
2. better SATD precision

EDIT4:
test5
1. Added mvsf.BlockFPS (someone, maybe, will ever use this thing?)

EDIT5:
test6
1. Fixed the crash of BlockFPS on GRAY clips

EDIT6:
test7
1. all 10 modes of dct are working now, "libfftw3f-3.dll" needs to be placed at the same folder with mvtools

EDIT7:
test8
1. Added mvsf.FlowFPS, wanna do some really fancy floating point precision slo-mo stuff? try it!
2. Added mvsf.FlowInter

EDIT8:
test9
1. Added mvsf.SCDetection

EDIT9:
test10
1. Added mvsf.Degrain4/5/6, these are the strict straight extensions of Degrain1/2/3, not like the approximate copycat python script

EDIT10:
test11
1. Binary Part: Extended Degrain to Degrain24 (24, it's my lucky number!)
2. Resurrected vmulti features from MVTools 2.6.0.5, implemented via a python module, "tr" works up to 24, guess no one will ever use a time radius > 24.... maybe?
3. Resurrected StoreVect and RestoreVect from MVTools 2.6.0.5, implemented via a python module

vmulti demos:
1. DegrainN

import vapoursynth as vs
import mvmulti
core = vs.get_core()
clp = xxx
sup = core.mvsf.Super(clp)
vec = mvmulti.Analyze(sup,tr=6,blksize=8,overlap=4)
vec = mvmulti.Recalculate(sup,vec,tr=6,blksize=4,overlap=2)
clp = mvmulti.DegrainN(clp, sup, vec, tr=6)
clp.set_output()


2. Compensate/Flow

import vapoursynth as vs
import mvmulti
core = vs.get_core()
clp = xxx
sup = core.mvsf.Super(clp)
vec = mvmulti.Analyze(sup,tr=6,blksize=8,overlap=4)
vec = mvmulti.Recalculate(sup,vec,tr=6,blksize=4,overlap=2)
clp = mvmulti.Compensate/Flow(clp, sup, vec, tr=6)
clp.set_output()


3.StoreVect (Return a vector clip that could be encoded by vspipe)
vec.vpy

import vapoursynth as vs
import mvmulti
core = vs.get_core()
clp = xxx
sup = core.mvsf.Super(clp)
vec = mvmulti.Analyze(sup,tr=6,blksize=8,overlap=4)
vec = mvmulti.Recalculate(sup,vec,tr=6,blksize=4,overlap=2)
vec = mvmulti.StoreVect(vec,"D:/vec.txt")
vec.set_output()

vspipe.exe vec.vpy D:\vec.rgb

4.RestoreVect (Restore the encoded vector clip back to a standard vector clip)

import vapoursynth as vs
import mvmulti
core = vs.get_core()
vec = mvmulti.RestoreVect("D:/vec.rgb","D:/vec.txt")


EDIT11:
test12
this one is, like, kinda free from runtime problems, the binary works without msvcr dlls, and silenced a warning in Overlap.cpp

EDIT12:
test13
precision boost
1. SAD (float -> double)
2. SATD (int16_t -> double)
3. DCT (uint8_t -> even more precise than float)
and also features some cosmetic changes from @ jackoneill

EDIT13:
test14
A. Full Precision Boost
1. DCT (float -> double)
2. Motion Analysis (float -> double)
3. Super (float -> double)
4. Overlap (float -> double)
5. Variance (float -> double)
6. Degrain (float -> double)
and more...
basically everything works at double precision, rounded to single precision only at the final output stage
binary compiled with strict floating point model settings (100% same like how IEEE defined how floating point calculation works)
B. Bug Fixes
fixed a bug inherited from the avisynth plugin (bit shift operation on negative values, reported by @Are_ via runtime debugging)

libfftw3-3.dll (not libfftw3f-3.dll) needs to be placed at the same folder with the plugin!!!

EDIT14:
test15
A. Colorspace
all floating point colorspaces are supported now, GrayS, RGBS and YUV4xxPS (note that dct 1-4 on YUV clips might be kind of buggy, as chroma features a different range from luma, will be fixed in the next release)
B. Degrain
the stupid "thsadc" and "limitc" parameters got their asses canceled, "thsad" and "limit" have been made arrays
"plane" parameter won't do nothing on RGB and GRAY clips, all planes will be processed
C. stuff, here and there..
bug fixes shamelessly copied from @jackoneill

EDIT15:
r1
first stable release!!!
A. sanity check.
will raise an error if the input is not single precision fp or features varying dimensions
B. DCT
fixed dct stuff on YUV input

EDIT16:
r2
merged bug fixes from jackoneill's branch since his last release
currently no plan to add depanning stuff

EDIT17:
r3
A. BlockFPS
1. added support to overlap (merged from Fizick's master branch)
2. new modes, mode 6-8, occlusion mask weighted on SAD (merged from Fizick's master branch)
B. Compensate
1. new parameter "time", use it to do partial time compensation (merged from Fizick's master branch)
C. Bug Fixes
1. vector length was clamped to 127/pel on motion flow functions, now it's 2147483647/pel, practically unlimited (Fizick relaxed it to 32767/pel, I decided to do it more thoroughly)
D. Precision Boost
1. internal masking for motion flow (uint8_t -> double)
2. simpleresize for masks (uint8_t -> double)
floating point precision MMask should be super easy to implement now (all internal stuff are double already), but I didn't do it anyways like, yeah, I'm all fucked up lazy

EDIT18:
r4
New Filter
binary: added mvsf.Flow
mvmulti: added mvmulti.Flow

EDIT19:
r5
Bug Fixes
1. truemotion was corrupted(bug inherited from jackoneill's branch), fixed.
2. the SATD implementation was completely incorrect, did some research and rewrote that from the beginning, SATD works correctly now

EDIT20:
r6:
new block sizes: 2x2, 64x64, 64x32, 128x128, 128x64, 256x256, 256x128
switched to fftw3.3.5

EDIT21:
r7
Bug Fix
fixed a clip length calculation bug in BlockFPS, reported by groucho86 (http://forum.doom9.org/showthread.php?p=1785268#post1785268)
New Feature
extended SATD to 64x64 128x128 and 256x256 blocks
Uncategorized
replaced Hadamard ordered SATD with the Sequency ordered variant, levels faster..

EDIT22:
r8
New Feature
mvsf.Mask
Uncategorized
converted some ugly C89 style code to C++14 style

EDIT22:
r9
fixed an ancient memory leak in mvsf.Super
converted some weird C++98 code to C++14

EDIT23:
major update:
- the mvmulti python module is now deprecated, all mvmulti stuff has been embedded into the C++ plugin.
- mvsf.Degrain can now handle arbitrary radius (not limited to 24)
- mvsf.Degrain1/Degrain2/.../Degrain24 are removed, the only MDegrain function is now mvsf.Degrain, which works for any radius.
- mvsf.Analyse is removed, type "Analyze" instead
- new parameter "radius" for mvsf.Analyze, when specified, mvsf.Analyze generates a compound vector clip that works for mvsf.Degrain/Compensate/Flow/Recalculate
- mvsf.Compensate/Flow/Recalculate automatically output compound results when provided a compound vector clip
- mvsf.Degrain automatically deduces the radius from the compound vector clip, you don't need to specify the radius
- when "radius" is specified for mvsf.Analyze, "isb" and "delta" are ignored.
- new parameter "cclip" for mvsf.Compensate/Flow, same as in the mvmulti python module, only takes effect for compound outputs.


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

#motion compensated dfftest
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.Compensate(clip, sup, vec)
clip = core.dfttest.DFTTest(clip, tbsize=2*6+1, tmode=0)
clip = core.std.SelectEvery(clip, 2*6+1, 6)


you need a C++20 compatible compiler and vsFilterScript (https://forum.doom9.org/showthread.php?t=181027) to build the binary.
the windows binary is currently unavailable because msvc does not support tons of C++20 core language features.

EDIT24:
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!

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

EDIT26:
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.

[Groucho2004]

I'm American and "analyse" always gets autocorrected and that's not nice
Do you write scripts on your phone?

[feisty2]

Do you write scripts on your phone?

http://i.imgur.com/uwRDrGc.png
"autocorrect" is available on PC also and besides, I just don't like "analyse", it looks creepy to me, "analyze" is way better

[feisty2]

test2: https://github.com/IFeelBloated/MVTools_SF/releases/tag/test2
1. Added SATD support (dct=5 works now)
2. Added mvsf.Finest (flow functions will be ready soon)

[feisty2]

test3: https://github.com/IFeelBloated/MVTools_SF/releases/tag/test3
1. Fixed possible overflow in SATD
2. Removed SATD for 8x4 16x8 8x16 blocks, no one uses them anyways
3. Added SATD support to 32x32 blocks
4. SATD for 16x16 blocks is corrupted in the original vaporsynth port, fixed now

[feisty2]

test4:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test4
1. Added mvsf.FlowBlur (you got a full floating point QTGMC now, if you want to)
2. better SATD precision

[feisty2]

test5:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test5
1. Added mvsf.BlockFPS (someone, maybe, will ever use this thing?)

[feisty2]

test6:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test6
1. Fixed the crash of BlockFPS on GRAY clips

[feisty2]

test7:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test7
1. all 10 modes of dct are working now, "libfftw3f-3.dll" needs to be placed at the same folder with mvtools

[feisty2]

test8:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test8
1. Added mvsf.FlowFPS, wanna do some really fancy floating point precision slo-mo stuff? try it!
2. Added mvsf.FlowInter

[feisty2]

test9:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test9
1. Added mvsf.SCDetection

[feisty2]

test10:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test10
1. Added mvsf.Degrain4/5/6, these are the strict straight extensions of Degrain1/2/3, not like the approximate copycat python script

[feisty2]

test11:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test11
1. Binary Part: Extended Degrain to Degrain24 (24, it's my lucky number!)
2. Resurrected vmulti features from MVTools 2.6.0.5, implemented via a python module, "tr" works up to 24, guess no one will ever use a time radius > 24.... maybe?
3. Resurrected StoreVect and RestoreVect from MVTools 2.6.0.5, implemented via a python module

[Boulder]

Now that DGDecodeNV has a 64-bit build to test, I also tried your plugin. I cannot get it to work, it only produces garbage on the screen.

https://drive.google.com/file/d/0BzeF_1syecQwdkFEN2t1YmswYXM/view?usp=sharing

import vapoursynth as vs
import havsfunc as has

core = vs.get_core()

clp = core.dgdecodenv.DGSource('c:/x265/hotfuzz.dgi')

clp = core.fmtc.bitdepth(clp, bits=16)

feed = has.DitherLumaRebuild(clp)

superanalyse = core.mvsf.Super(feed,pel=2)
supermdg = core.mvsf.Super(clp,pel=2)

bv1 = core.mvsf.Analyse(superanalyse, dct=0, blksize=16, overlap=8, isb=True)
fv1 = core.mvsf.Analyse(superanalyse, dct=0, blksize=16, overlap=8)

finalclip = core.mvsf.Degrain1(clp, supermdg, bv1, fv1, thsad=300, thsadc=300, limit=1.0, limitc=1.0)

finalclip.set_output()

[feisty2]

It works at 32bits float (aka Single Precision) ONLY

[Boulder]

Why not make a sanity check then?

[feisty2]

Cuz I already said "single precision" at the title of the thread:)
And I'm lazy like hell
Anyways, it's an addition not a replacement to jackoneill's mvtools

[feisty2]

test12:https://github.com/IFeelBloated/MVTools_SF/releases/tag/test12
this one is, like, kinda free from runtime problems, the binary works without msvcr dlls, and silenced a warning in Overlap.cpp

[sl1pkn07]

you can add a "configure" for build the plugin?

greetings

[feisty2]

you can add a "configure" for build the plugin?

greetings

wish I could, but I'm just no good at gnu stuff...
guess the configure files from jackoneill's version will just work, but no guarantee about that..
I'd be happy to add those configure files to the master branch if you'd like to make them..

[feisty2]

@sl1pkn07
thanks to Are_'s help, the compiling files are available now

[sl1pkn07]

zankius!

[feisty2]

https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/test13
test13
precision boost
1. SAD (float -> double)
2. SATD (int16_t -> double)
3. DCT (uint8_t -> even more precise than float)
and also features some cosmetic changes from @ jackoneill

[feisty2]

https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/test14
test14
A. Full Precision Boost
1. DCT (float -> double)
2. Motion Analysis (float -> double)
3. Super (float -> double)
4. Overlap (float -> double)
5. Variance (float -> double)
6. Degrain (float -> double)
and more...
basically everything works at double precision, rounded to single precision only at the final output stage
B. Bug Fixes
fixed a bug inherited from the avisynth plugin (bit shift operation on negative values, reported by @Are_ via runtime debugging)

[Myrsloik]

https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/test14
test14
A. Full Precision Boost
1. DCT (float -> double)
2. Motion Analysis (float -> double)
3. Super (float -> double)
4. Overlap (float -> double)
5. Variance (float -> double)
6. Degrain (float -> double)
and more...
basically everything works at double precision, rounded to single precision only at the final output stage
B. Bug Fixes
fixed a bug inherited from the avisynth plugin (bit shift operation on negative values, reported by @Are_ via runtime debugging)

I'm curious now. Did you compare the speed between your single and double precision versions? I suspect you've made it even slower now.

[feisty2]

I'm curious now. Did you compare the speed between your single and double precision versions? I suspect you've made it even slower now.

the speed is only a little bit slower than single precision version long as FFTW stays out of business, but drops heavily (~2x slower on my i7-4790k) if FFTW gets involved (dct=1-4)

[MonoS]

Probably you'll see some speed difference if you enable auto vectorization [on GCC -O3 and -march=corei7-avx]. Right now it isn't any slower because latency between float and double is the same [5 cycles on the latest intel generation], the little speed difference is probably due to memory access, fftw is 2x slower due to loss in vectorization [in a 128bit vector register can fit 4 floats but only 2 doubles].

I'll be more interested to know if this precision boost is really useful

[feisty2]

I'll be more interested to know if this precision boost is really useful

floats lose precision as the calculation goes on, and giant plugin like mvtools comes with hell lot of calculations, double precision is required to do the intermediate stuff if you want the final output features a real single precision, otherwise it's just low precision data in a single precision format..

[MonoS]

floats lose precision as the calculation goes on, and giant plugin like mvtools comes with hell lot of calculations, double precision is required to do the intermediate stuff if you want the final output features a real single precision, otherwise it's just low precision data in a single precision format..

Sorry if i ask, but i'd like to see some real world example.

While i understand the using of single precision for this kind of calculation, i think that double is rather overkill.
But let make clear that this my statement is not supported by actual facts, i'm willing to change my mind [but please, try to make some better example than the one you did on fmtc thread]

[feisty2]

https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/test15
test15
A. Colorspace
all floating point colorspaces are supported now, GrayS, RGBS and YUV4xxPS (note that dct 1-4 on YUV clips might be kind of buggy, as chroma features a different range from luma, will be fixed in the next release)
B. Degrain
the stupid "thsadc" and "limitc" parameters got their asses canceled, "thsad" and "limit" have been made arrays
"plane" parameter won't do nothing on RGB and GRAY clips, all planes will be processed
C. stuff, here and there..
bug fixes shamelessly copied from @jackoneill

[feisty2]

so I been testing, RGB colorspace has been supported but,
I found motion estimating under RGB is not some kind of nice thing to do, I mean, it works, but the quality sucks comparing to just do it under YUV 4:4:4
convert your RGB input to YUV before applying mvtools on it, or, anyways, mvtools will happily take the RGB input and feed you back with some shitty motion estimation if you give it like some RGB input directly

[feisty2]

https://github.com/IFeelBloated/vapoursynth-mvtools-sf/releases/tag/r1
r1
first stable release!!!
A. sanity check.
will raise an error if the input is not single precision fp or features varying dimensions
B. DCT
fixed dct stuff on YUV input

[Mystery Keeper]

Works awesomely. Thank you!

[feisty2]

r2
merged bug fixes from jackoneill's branch since his last release
currently no plan to add depanning stuff

[feisty2]

r3
A. BlockFPS
1. added support to overlap (merged from Fizick's master branch)
2. new modes, mode 6-8, occlusion mask weighted on SAD (merged from Fizick's master branch)
B. Compensate
1. new parameter "time", use it to do partial time compensation (merged from Fizick's master branch)
C. Bug Fixes
1. vector length was clamped to 127/pel on motion flow functions, now it's 2147483647/pel, practically unlimited (Fizick relaxed it to 32767/pel, I decided to do it more thoroughly)
D. Precision Boost
1. internal masking for motion flow (uint8_t -> double)
2. simpleresize for masks (uint8_t -> double)
floating point precision MMask should be super easy to implement now (all internal stuff are double already), but I didn't do it anyways like, yeah, I'm all fucked up lazy

[Mystery Keeper]

You say it is possible to write QTGMC analog for floating point. Can you please give a code to replace TemporalSoften?

[feisty2]

r4
New Filter
binary: added mvsf.Flow
mvmulti: added mvmulti.Flow

[~SimpleX~]

VS Editor crashes on simple

import vapoursynth as vs
core = vs.get_core()

src = core.d2v.Source(...)
last = core.fmtc.bitdepth(src, bits=32, fulls=False, fulld=True)
super = core.mvsf.Super(last)
last.set_output()


Latest test version of VS r33, mvsf r4.

[feisty2]

VS Editor crashes on simple

import vapoursynth as vs
core = vs.get_core()

src = core.d2v.Source(...)
last = core.fmtc.bitdepth(src, bits=32, fulls=False, fulld=True)
super = core.mvsf.Super(last)
last.set_output()


Latest test version of VS r33, mvsf r4.

does your CPU feature the AVX2 extension?

[~SimpleX~]

does your CPU feature the AVX2 extension?

Oh, well, it doesn't. I have i7 2600k, which is Sandy Bridge. :(

[feisty2]

Oh, well, it doesn't. I have i7 2600k, which is Sandy Bridge. :(

then you have to compile a compatible binary yourself, auto compiling files for GCC are provided with the source code

[kolak]

Is there a real gain in quality due to such a high precision implementation?

[feisty2]

Is there a real gain in quality due to such a high precision implementation?

guess there's quality gain more or less, but mainly for being free of clamping (more mathematically correct) in floating point format rather than higher precision

[kolak]

I've tried it and have not seen any "real" difference.

[feisty2]

I've tried it and have not seen any "real" difference.

you might not see any "real" difference between int8 and int16 most of the time, not to even mention int16 and float32

I started this for my OCD about placebo precision, wanted it to be as mathematically correct as possible, but the actual reason that makes this useful is there're HDR videos out there, HDR videos contain colors even brighter than white or even darker than black, and integers couldn't handle stuff like that, and floats could.

[kolak]

I'm not trying to say your work is worthless.
Nothing wrong with having options as there may be cases when it may be useful (as you already mentioned).

[feisty2]

r5
Bug Fixes
1. truemotion was corrupted(bug inherited from jackoneill's branch), fixed.
2. the SATD implementation was completely incorrect, did some research and rewrote that from the beginning, SATD works correctly now

[feisty2]

@~SimpleX~
r5 features no SIMD extension, try it and it will probably not crash this time

[~SimpleX~]

I've made some stupid compatibility layer for mv and mvsf (https://gist.github.com/SX91/9e65814384a9f23535077366996097ea) (mvmulti, 8..32 bit support, incomplete function set). Maybe it would be useful for someone.

[Myrsloik]

I've made some stupid compatibility layer for mv and mvsf (https://gist.github.com/SX91/9e65814384a9f23535077366996097ea) (mvmulti, 8..32 bit support, incomplete function set). Maybe it would be useful for someone.

You should check sample_type, not the number of bits

[~SimpleX~]

You should check sample_type, not the number of bits

Missed that part, thanks! Updated.

[feisty2]

Missed that part, thanks! Updated.

theoretically you cannot expand DegrainN to the partial sum of a series like ∑[x=1, y](DegrainRadius[x] * P[x]) (∑[x=1, y]Radius[x] = N, ∑[x=1, y]P[x]=1), it works but the result is very different from DegrainN


mv123 = core.mv.Degrain3(clip, super, *v[:6], **kwargs)
mv456 = core.mv.Degrain3(clip, super, *v[6:], **kwargs)
sm = core.std.Merge(mv123, mv456, 0.4615)

is poles apart from mvsf.Degrain6, and you should not obfuscate them in your "degrain" function.

edit: made the statement more rigorous

[~SimpleX~]

theoretically you cannot expand DegrainN to the partial sum of a series like ∑[x=1, y](DegrainRadius[x] * P[x]) (∑[x=1, y]Radius[x] = N, ∑[x=1, y]P[x]=1), it works but the result is very different from DegrainN


mv123 = core.mv.Degrain3(clip, super, *v[:6], **kwargs)
mv456 = core.mv.Degrain3(clip, super, *v[6:], **kwargs)
sm = core.std.Merge(mv123, mv456, 0.4615)

is poles apart from mvsf.Degrain6, and you should not obfuscate them in your "degrain" function.

edit: made the statement more rigorous
I took that code from MCTemporalDenoise. I'd love to have Degrain at least up to 6 in jackoneill's plugin, but for now... Maybe I should remove that part completely and stick to Degrain1..Degrain3 for integral samples?

[feisty2]

I took that code from MCTemporalDenoise. I'd love to have Degrain at least up to 6 in jackoneill's plugin, but for now... Maybe I should remove that part completely and stick to Degrain1..Degrain3 for integral samples?

remove it, definitely, nothing wrong with this approach, it's just DIFFERENT from how DegrainN works in mvtools and you should never obfuscate different stuff together like they are the same stuff..

[feisty2]

r6:
new block sizes: 2x2, 64x64, 64x32, 128x128, 128x64, 256x256, 256x128
switched to fftw3.3.5

[groucho86]

Hi feisty2,
I'm using BlockFPS to get to a lower FPS (29.97i to 59.94p via QTGMC then to 23.976p) using this code :
clp = core.fmtc.bitdepth(clip,bits=32,fulls=False,fulld=True)
super = core.mvsf.Super(clp,pel=4,hpad=16,vpad=16,rfilter=4)
bw_1 = core.mvsf.Analyze(super,isb=True,blksize = 16,overlap=0,search=3,badrange =-24)
fw_1 = core.mvsf.Analyze(super,isb=False,blksize = 16,overlap=0,search=3,badrange =-24)
clp = core.mvsf.BlockFPS(clp, super, bw_1, fw_1, num=24000, den=1001, blend=False)

clp.set_output()

The video freezes about halfway through. I wonder if it's similar to the problem that was fixed in jackoneill's version (https://github.com/dubhater/vapoursynth-mvtools/commit/435be3fa3f1f21d8434c69aa3a2801f4765fbe85).

[feisty2]

r7
Bug Fix
fixed a clip length calculation bug in BlockFPS, reported by groucho86
New Feature
extended SATD to 64x64 128x128 and 256x256 blocks
Uncategorized
replaced Hadamard ordered SATD with the Sequency ordered variant, levels faster..

[Mystery Keeper]

Could you please do Mask too? I found it can be used to limit the destructive effect of temporal denoising.

[feisty2]

Could you please do Mask too? I found it can be used to limit the destructive effect of temporal denoising.

will do that for the next update

[feisty2]

r8
New Feature
mvsf.Mask
Uncategorized
converted some ugly C89 style code to C++14 style

[feisty2]

Could you please do Mask too? I found it can be used to limit the destructive effect of temporal denoising.

done!

[feisty2]

anyone needs AVX/FMA optimizations for this thing?
I'll do it if I got 2 or more replies for "yes"

[Mystery Keeper]

anyone needs AVX/FMA optimizations for this thing?
I'll do it if I got 2 or more replies for "yes"Yes! And thank you very much for the Mask!

[MonoS]

anyone needs AVX/FMA optimizations for this thing?
I'll do it if I got 2 or more replies for "yes"

You can find an implementation in my repo, but be aware that is a bit slower than compiling it on -O3 on GCC

[feisty2]

You can find an implementation in my repo, but be aware that is a bit slower than compiling it on -O3 on GCC

but that's not my floating point version...

[Mystery Keeper]

You can find an implementation in my repo, but be aware that is a bit slower than compiling it on -O3 on GCC-O3 is not to be trusted. It is experimental. Any compiler features that prove safe and sensible quickly get moved into -O2.

[Pat357]

I'd like to compile this myself, but it didn't work out yet.
Is it possible that you did some renaming of the files ?
The current generated Makefile by Configure-script gives an error :

checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking pkg-config is at least version 0.9.0... yes
checking for VapourSynth... yes
checking for FFTW3... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
make: *** No rule to make target 'src/DCT.cpp', needed by 'src/DCT.lo'. Stop.

Seams DCT.cpp is no longer in /src

Can you have a look at this ?

Thanks !

[feisty2]

I'd like to compile this myself, but it didn't work out yet.
Is it possible that you did some renaming of the files ?
The current generated Makefile by Configure-script gives an error :

checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking pkg-config is at least version 0.9.0... yes
checking for VapourSynth... yes
checking for FFTW3... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
make: *** No rule to make target 'src/DCT.cpp', needed by 'src/DCT.lo'. Stop.

Seams DCT.cpp is no longer in /src

Can you have a look at this ?

Thanks !

done!

[Pat357]

Thanks for the fast response !
The compile seems to work, but I noticed a lot "unused" warnings....
When linking starts, things go wrong :
CXXLD libmvtoolssf.la
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text+0x6a): undefined reference to `__imp_pthread_mutex_destroy'
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text+0x940): undefined reference to `__imp_pthread_mutex_lock'
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text+0x987): undefined reference to `__imp_pthread_mutex_unlock'
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text.startup+0xf): undefined reference to `__imp_pthread_mutex_init'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text+0x7a): undefined reference to `__imp_pthread_mutex_destroy'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text+0x1e32): undefined reference to `__imp_pthread_mutex_lock'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text+0x1e77): undefined reference to `__imp_pthread_mutex_unlock'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text.startup+0xf): undefined reference to `__imp_pthread_mutex_init'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:502: libmvtoolssf.la] Error 1


Any idea how to make this work ?
Do you have an idea why just these two MVAnalyze.cpp and MVRecalculate.cpp have this problem with linking threads-lib ?

My build-system : Mingw64 and GCC 6.3.0 / Msys2 / Win7 SP1 / Haswell
FFTW3 installed (from Mingw64)
Vapoursynth installed

Tested adding -mthreads or -pthread to CXXFLAGS , but had no effect
adding LIBS=-lpthread to environment didn't help.

Open for ideas !

[feisty2]

I guess the warnings are probably related to "g_fftw_plans_mutex" (a static mutex variable in DCTFFTW.hpp)
I did all my developing under Visual Studio 2017 and there was no warning or error building the plugin (Visual Studio simplified "compile + link" to one click of "build", and then generates binary automatically)
I know pretty much nothing about GNU compilers, I think you might have to ask someone else who's more familiar with GNU about those warnings and errors..

[jackoneill]

Thanks for the fast response !
The compile seems to work, but I noticed a lot "unused" warnings....
When linking starts, things go wrong :
CXXLD libmvtoolssf.la
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text+0x6a): undefined reference to `__imp_pthread_mutex_destroy'
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text+0x940): undefined reference to `__imp_pthread_mutex_lock'
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text+0x987): undefined reference to `__imp_pthread_mutex_unlock'
src/.libs/MVAnalyze.o:MVAnalyze.cpp:(.text.startup+0xf): undefined reference to `__imp_pthread_mutex_init'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text+0x7a): undefined reference to `__imp_pthread_mutex_destroy'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text+0x1e32): undefined reference to `__imp_pthread_mutex_lock'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text+0x1e77): undefined reference to `__imp_pthread_mutex_unlock'
src/.libs/MVRecalculate.o:MVRecalculate.cpp:(.text.startup+0xf): undefined reference to `__imp_pthread_mutex_init'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:502: libmvtoolssf.la] Error 1


Any idea how to make this work ?
Do you have an idea why just these two MVAnalyze.cpp and MVRecalculate.cpp have this problem with linking threads-lib ?

My build-system : Mingw64 and GCC 6.3.0 / Msys2 / Win7 SP1 / Haswell
FFTW3 installed (from Mingw64)
Vapoursynth installed

Tested adding -mthreads or -pthread to CXXFLAGS , but had no effect
adding LIBS=-lpthread to environment didn't help.

Open for ideas !

You're using Mingw's winpthreads, right? If you compiled it static only you need to modify pthread.h a little:

--- mingw-w64-libraries/winpthreads/include/pthread.h 2014-10-26 04:11:33.000000000 +0200
+++ mingw-w64-libraries/winpthreads/include/pthread.h 2014-12-10 14:17:45.542746397 +0200
@@ -82,7 +82,9 @@
/* MSB 8-bit major version, 8-bit minor version, 16-bit patch level. */
#define __WINPTHREADS_VERSION 0x00050000

-#if defined DLL_EXPORT
+/* No __declspec crap needed when winpthreads is static.
+ * In fact, it produces linker errors (can't find __imp_blah). */
+#if defined DLL_EXPORTzzzzzzzzzzz
#ifdef IN_WINPTHREAD
#define WINPTHREAD_API __declspec(dllexport)
#else

Maybe you could report this bug and make them fix it.

[Pat357]

You're using Mingw's winpthreads, right?
Thanks !

Even when I tried with -mthreads , it gives the same error.

I'll try the patch and let you know.

PS : Compiled again with patch applied and tested : working 100 %

[MonoS]

but that's not my floating point version...

The code will be almost the same i suppose

[MonoS]

-O3 is not to be trusted. It is experimental. Any compiler features that prove safe and sensible quickly get moved into -O2.

-O3, for my interest, enable autovectorization and this feature, as i read on twitter from trustworthy people, may produce awful SIMD code, probably that's why it's still in O3 as you suggest (i didn't know about that, where did you read that?)

[feisty2]

r9
fixed an ancient memory leak in mvsf.Super
converted some weird C++98 code to C++14

[Efenstor]

Can't compile neither the master nor latest release:
make: *** No rule to make target 'src/FakeGroupOfPlanes.cpp', needed by 'src/FakeGroupOfPlanes.lo'. Stop.
make: *** Waiting for unfinished jobs....

[Are_]

Master will work if you go one commit back or if you delete the src/FakeGroupOfPlanes.cpp line in Makefile.am, probably.

[feisty2]

fixed

[cwk]

Getting the following error when attempting to compile master:

src/MVClip.hpp:21:56: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
auto evil = vsapi->getFrame(0, vectors, errorMsg.data(), MaxErrorLength);
^
...

Makefile:537: recipe for target 'src/GroupOfPlanes.lo' failed
make: *** [src/GroupOfPlanes.lo] Error 1

My sequence is:

autogen.sh
configure
make

Any ideas?

[feisty2]

C++17 support is required, the non-const version of "data()" is new in C++17

[cwk]

Thanks for the tip. With that in mind, I am able to compile r7 on Ubuntu 16.04 without too much difficulty.

Any ideas when gnu will offer support for that version of data()? It looks like the makefile is already geared up with that flag:

AM_CXXFLAGS = -O2 -std=c++1z -msse2 -mfpmath=sse $(STACKREALIGN) -Wall -Wextra -Wno-unused-parameter -Wshadow

I modified the flag to: "-std=c++17" specifically, which didn't appear to have any impact.

[Are_]

Gcc 7

[shader]

does your CPU feature the AVX2 extension?

I'm run VS on two different laptops. On is a little bit older and therefore it does not have AVX2 extension.

Does anybody compile the latest release for 64 bit without AVX2 and wants to share it with me?

Thanks!

[chawl]

I'm run VS on two different laptops. On is a little bit older and therefore it does not have AVX2 extension.

Does anybody compile the latest release for 64 bit without AVX2 and wants to share it with me?

Thanks!

I had the same problem so I compiled the latest (R9) source on MinGW for my good old Phenom II X6 and it may work for you too, so here it is:

https://drive.google.com/file/d/0BxnWzTDZM0v5M2hfTmtvTXI0Njg/view?usp=sharing

You have to put all DLLs under plugins64 directory as my build is not as static as feisty2's and has two dependencies. I also added libfftw3-3.dll.bak file for any reason that your version of FFTW might not work, just rename back to .dll to use it.

[ChaosKing]

Does your mvtools version has some other dependency except libfftw3-3.dll ? It works on my Desktop PC but not on a Win server 2012. I installed every c/c++ runtime I could think of.

This is the script I'm using https://forum.doom9.org/showthread.php?p=1833133#post1833133

I get this error using VS R43 x64:
Problem Event Name: APPCRASH
Application Name: vspipe.exe
Application Version: 0.0.0.0
Application Timestamp: 5a721c1c
Fault Module Name: libmvtools_sf_em64t.dll
Fault Module Version: 0.0.0.0
Fault Module time stamp: 59492968
Exception code: c000001d
Except Offset: 00000000000ea5fd
OS Version: 6.2.9200.2.0.0.272.7
Locale ID: 1031
Additional information 1: e868
Additional Information 2: e8684f6eaacb2ee3a8b23fd72a9ac907
Additional information 3: b387
Additional Information 4: b38712ff53fac18241870cc7b35aa182

[feisty2]

could be hardware related, does the cpu of ur server support avx2 instruction set?
if not, u should probably compile a binary for ur own hardware

[ChaosKing]

It's a i7 3770, only AVX :( https://ark.intel.com/de/products/65719/Intel-Core-i7-3770-Processor-8M-Cache-up-to-3_90-GHz

//Edit: The compiled dll by chawl works, thx!

[ChaosKing]

Could someone compile a new x64 binary (non avx2) of this filter? chawl's version produces some green frames with R43. Thank you!

[ChaosKing]

Thank you HolyWu.
But something is still not right. Both compiled version (sse and avx) produces also broken images. The sse version shows a green overlay I think. The strange part is, that all dlls work fine with my ryzen 1700(supports AVX2). But on a i5 3770 it's garbage.

https://i.imgur.com/Ffwxmim.jpg

[Myrsloik]

So this plugin requires the double precision fftw3 dll? Or am I mistaken?

[tormento]

URL]http://www.mediafire.com/file/a92cznircpr34r2/libmvtools_sf_em64t.7z[/URL]
Link expired. Could you please give a mirror?

Unfortunately no AVX2 here too.

[feisty2]

this plugin is a gigantic mess, I might have to rewrite it from the scratch someday...

[feisty2]

major update:
- the mvmulti python module is now deprecated, all mvmulti stuff has been embedded into the C++ plugin.
- mvsf.Degrain can now handle arbitrary radius (not limited to 24)
- mvsf.Degrain1/Degrain2/.../Degrain24 are removed, the only MDegrain function is now mvsf.Degrain, which works for any radius.
- mvsf.Analyse is removed, type "Analyze" instead
- new parameter "radius" for mvsf.Analyze, when specified, mvsf.Analyze generates a compound vector clip that works for mvsf.Degrain/Compensate/Flow/Recalculate
- mvsf.Compensate/Flow/Recalculate automatically output compound results when provided a compound vector clip
- mvsf.Degrain automatically deduces the radius from the compound vector clip, you don't need to specify the radius
- when "radius" is specified for mvsf.Analyze, "isb" and "delta" are ignored.
- new parameter "cclip" for mvsf.Compensate/Flow, same as in the mvmulti python module, only takes effect for compound outputs.


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

#motion compensated dfftest
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.Compensate(clip, sup, vec)
clip = core.dfttest.DFTTest(clip, tbsize=2*6+1, tmode=0)
clip = core.std.SelectEvery(clip, 2*6+1, 6)


you need a C++20 compatible compiler and vsFilterScript (https://forum.doom9.org/showthread.php?t=181027) to build the binary.
the windows binary is currently unavailable because msvc does not support tons of C++20 core language features.

[ChaosKing]

Wow that's awesome :eek:
How is the speed compared to your previous implementation?
Does this version also supports 8..16 bits per sample?

[feisty2]

Wow that's awesome :eek:
How is the speed compared to your previous implementation?
Does this version also supports 8..16 bits per sample?

there's no noticeable speed difference.
no, it still only works for fp32 inputs

[feisty2]

can someone please build a binary for windows?
the binary I built relies on a bunch of Cygwin dlls.

to build the binary, you need to:
1) get "Include" folder from vsFilterScript
2) place "VapourSynth.h", "VSHelper.h", "fftw3.h" in the "Include" folder
3) compile and link "vapoursynth.lib", "libfftw3-3.lib"

[Are_]

It doesn't build on Linux :(

g++ -std=c++20 -IvsFilterScript -I/usr/include/vapoursynth -shared -fPIC -march=native -Ofast -o libmvtoolssf.so src/EntryPoint.cxx -lvapoursynth -lfftw3
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/g++-v10/cmath:45,
from vsFilterScript/Include/Infrastructure.hxx:15,
from vsFilterScript/Include/Range.hxx:2,
from vsFilterScript/Include/Plane.hxx:2,
from vsFilterScript/Include/Frame.hxx:3,
from vsFilterScript/Include/Clip.hxx:2,
from vsFilterScript/Include/Map.hxx:2,
from vsFilterScript/Include/Plugin.hxx:2,
from vsFilterScript/Include/Core.hxx:2,
from vsFilterScript/Include/Interface.hxx:2,
from src/EntryPoint.cxx:1:
src/Overlap.h:5:16: error: expected unqualified-id before numeric constant
5 | constexpr auto M_PI = 3.1415926535897932384626433832795;
|
$ LANG=C gcc --version
gcc (Gentoo 10.1.0 p1) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Also could you consider using the normal include paths for vapoursynth and fftw3? The way things are now break packaging.

[feisty2]

I'm sure the code is correct, did you turn on some weird floating point flags (such that floating point literals are not assumed to be constants)?

[pinterf]

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

[Are_]

Nope, and shouldn't that had to be done in the source itself?

[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].