MVTools-pfmod

[StainlessS]

GMJCZP,

Well that Fizick, or whoever designed this stuff is well more clever than I gave credit for, thank you for the education, we need as much of that as we can get. :)

[GMJCZP]

I give you the whole reason, Fizick, cretindesalpes, pinterf are geniuses.

[GMJCZP]

@ pinterf:

I noticed that the parameter search = 5 (Umh) produces identical results as search = 4 (Hex). In x264 the results are different.

[burfadel]

Life is simpler than you think, TinMan:

# MDegrainLight
# https://forum.doom9.org/showthread.php?p=1813061#post1813061
# Original idea by hello_hello
# Adapted by GMJCZP
# Requirements: MVTools, Dither Tools (optional for lsb=true)

function MDegrainLight(clip input, int "tr", bool "mt", bool "lsb", int "thSAD", int "thSAD2", int "blksize", int "overlap")
{
tr = Default(tr, 1) # Temporal radius
mt = Default(mt, true) # Internal multithreading
lsb = Default(lsb, false) # 16-bit
thSAD = Default(thSAD, 200) # Denoising strength
thSAD2 = Default(thSAD2, 150)
blksize = Default(blksize, 16) # Block size
overlap = Default(overlap, 4) # Block overlap

# <Options for lsb=true>
#input = lsb ? input.DitherPost() : input # For AVS, AVS+ users
#input = lsb ? input.ConvertFromStacked() : input # For AVS+ only, more slow, suggestion of blaze077

super = input.MSuper (mt=mt)
multi_vec = MAnalyse (super, mt=mt, multi=true, blksize=blksize, overlap=overlap, delta=tr)
multi_vec_re = MRecalculate(super,multi_vec, tr=tr,blksize=4)
input.MDegrainN (super, multi_vec_re, tr, mt=mt, lsb=lsb, thSAD=thSAD, thSAD2=thSAD2)
# return lsb ? ConvertToStacked() : last # For AVS+ only, more slow, suggestion of blaze077
return last
}

:)

I have found that processing chroma and luma separately produces nicer results in regards to mdegrain. I came up with the following script based on existing Mdegrain concept, in conjuction with a luma mask I borrowed from the linked post. The luma mask is beneficial in reducing motion artifacts.

In this script luma is handed by MVtools and chroma is handled by FFT3DFilter. FFT3DFilter seems more appropriate for chroma, and MVTools seems more appropriate for luma according to the results that each achieves. On a clip I tried it also was worked as a de-rainbow filter, although the effect is likely quite weak.

# MClean basic script
# Mask from bennynihon https://forum.doom9.org/showthread.php?p=1689444#post1689444
# Remaining script by burfadel altered from generic information
# Basics for this script is to remove grain whilst retaining as much information as possible
# The script should also be relatively fast, even without Masktools2 multithreading (disabled due to possible MT bug)
# Chroma is processed via a different method to luma for optimal results
# Requires RGTools, Modplus (Veed, for part of chroma filter), MVTools2, Masktools2, FFT3DFilter


function MClean(clip c, int "thSAD", int "blksize", int "blksizeV", int "overlap", int "cblksize", int "cblksizeV", int "cpu")
{
thSAD = Default(thSAD, 350) # Denoising threshold
blksize = Default(blksize, 16) # Horizontal block size for luma
blksizeV = Default(blksizeV, blksize) # Vertical block size for luma, default same as horizontal
overlap = Default(overlap, 8) # Block overlap
cblksize = Default(cblksize, 32) # Horizontal block size for chroma
cblksizeV = Default(cblksizeV, cblksize) # Vertical block size for chroma, default same as horizontal
cpu = Default(cpu, 4) # Threads for FFT3DFilter

coverlapH = (cblksize/2) # Overlap for horizontal chroma blocks, half blksize
coverlapV = (cblksizeV/2) # Overlap for vertical chroma blocks, half blksizeV


# Masks
LumaMask=mt_binarize(c, threshold=64, upper=true).greyscale().BilinearResize((c.width/16)*2, (c.height/16)*2).BilinearResize(c.width,c.height).mt_binarize(threshold=254)
EdgeMask=mt_edge(c, mode="prewitt",thy1=0,thy2=16).greyscale().mt_binarize(threshold=16, upper=true).BilinearResize((c.width/16)*2, (c.height/16)*2).BilinearResize(c.width,c.height).mt_binarize(threshold=254)
GrainMask=mt_logic(LumaMask,EdgeMask,mode="and")
DegrainMask=GrainMask.mt_invert()

# Chroma filter
filt_chroma=fft3dfilter(veed(c), plane=3, bw=cblksize, bh=cblksizeV, ow=coverlapH, oh=coverlapV, bt=5, sharpen=0.6, ncpu=cpu, dehalo=0.2, sigma=2.35)

# Luma Filter
super = c.MSuper(rfilter=4, chroma=false,hpad=16, vpad=16)
bvec2 = MAnalyse(super, chroma=false, isb = true, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=5)
bvec1 = MAnalyse(super, chroma=false, isb = true, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=3)
fvec1 = MAnalyse(super, chroma=false, isb = false, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=3)
fvec2 = MAnalyse(super, chroma=false, isb = false, delta = 2, blksize=blksize, blksizeV=blksizeV, overlap=overlap, search=5, searchparam=5)
Clean = c.MDegrain2(super, bvec1, fvec1, bvec2, fvec2, thSAD=thSAD, plane = 0)

#Luma mask merge
filt_luma = c.mt_merge(Clean, DegrainMask, U=1, V=1)

# Combining result of luma and chroma cleaning
output = mergechroma(filt_luma, filt_chroma)

return output
}

Yes, no doubt it could be improved, but it produces pretty good results. I guess from that you could add dither.

[MysteryX]

Hey, quick question. MvTools2 has performance and stability issues with MT, especially when using DCT=1. Does the VapourSynth version also have such issues or does it work smoothly there?

[blaze077]

It works perfectly even with DCT=1 for me. I've never encountered a problem with it (because of Vapoursynth's stable MT).

[hello_hello]

GMJCZP,
Thanks for the credit in your script, but I must confess the idea was not mine.
Im pretty sure I stole it from this post.
https://forum.doom9.org/showthread.php?p=1583955#post1583955

[GMJCZP]

GMJCZP,
Thanks for the credit in your script, but I must confess the idea was not mine.
Im pretty sure I stole it from this post.
https://forum.doom9.org/showthread.php?p=1583955#post1583955

Thank you for your honesty. You have not stolen anything, just the circumstances. ;)

I updated the script just to reflect this.

[MysteryX]

Does DCT=1 have the same issues with BlkSize=8 that doesn't use FFTW?


ColorBarsHD()
ConvertToYV12()
jm_fps()
Prefetch(8)

function jm_fps(clip source, float "fps")
{
fps = default(fps, 60)
fps_num = int(fps * 1000)
fps_den = 1000

prefiltered = RemoveGrain(source, 22)
super = MSuper(source, hpad = 16, vpad = 16, levels = 1) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad = 16, vpad = 16) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize = 8, overlap = 4, search = 3, dct = 1)
forward = MAnalyse(superfilt, isb = false, blksize = 8, overlap = 4, search = 3, dct = 1)
forward_re = MRecalculate(super, forward, blksize = 4, overlap = 2, thSAD = 100)
backward_re = MRecalculate(super, backward, blksize = 4, overlap = 2, thSAD = 100)
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)

return out
}



Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\SysWOW64\KernelBase.dll
Address: 0x76C3A9F2

WOOPS!!

[VS_Fan]

Does DCT=1 have the same issues with BlkSize=8 that doesn't use FFTW?It looks like your problem is not related to DCT=1 in MAnalyse, but instead with different blocksizes and overlaps in MAnalyse and MRecalculate.

I had a similar crash problem with FFTW related to mvtools2 in a script some time ago with SET’s avisyth 2.6 MT and Firesledge’s mvtools 2.6.0.5. So I tried my old solution in your script, appending mt=False to MSuper, MAnalyse and MRecalculate, but that didn’t help. It still crashes.

Then I tried changing MRecalculate with the same blocksize and overlap you used in MAnalyse. This effectively prevents the crash in your script. Although it unfortunately is not what you intend to do, I hope this helps to find a potential bug in MVTools-pfmod.

[MysteryX]

Indeed it crashes with the combination of BlkSize and Overlap. If I set Overlap=0, it doesn't crash.

Performance-wise, BlkSize=8 runs at 51% CPU with 8 threads (1080p with 0 overlap)

FPS (min | max | average): 1.308 | 101671 | 8.866
Memory usage (phys | virt): 1531 | 1537 MiB
Thread count: 29
CPU usage (average): 51%


BlkSize=16 runs at 39% CPU and is much slower

FPS (min | max | average): 0.313 | 83516 | 3.048
Memory usage (phys | virt): 1429 | 1431 MiB
Thread count: 29
CPU usage (average): 39%


BlkSize=12 is even slower

FPS (min | max | average): 0.294 | 93537 | 2.691
Memory usage (phys | virt): 1387 | 1389 MiB
Thread count: 29
CPU usage (average): 39%

BlkSize=8 with DCT=0 runs at 64% CPU and is only twice faster than DCT=1

FPS (min | max | average): 2.481 | 97435 | 15.34
Memory usage (phys | virt): 1528 | 1540 MiB
Thread count: 29
CPU usage (average): 64%

[manolito]

Which version of fftw3.dll are you guys using? The plugin archive comes with three different versions (float, double and long), and after doing some research I always use the float version. Could different versions be responsible for the speed differences with DCT=1 ?

[StainlessS]

Already posted about it somewhere, Pinterf fixed it in his later builds.
OverLap has to be 0 in some builds on final use of vectors.

Something bout it here:

https://forum.doom9.org/showthread.php?p=1785084#post1785084
https://forum.doom9.org/showthread.php?p=1785099#post1785099
https://forum.doom9.org/showthread.php?p=1785795#post1785795

EDIT:
Mani, libfftw3f-3.dll. Also use renamed to fftw3.dll (Although some plugins were fixed to use either name).

[poisondeathray]

Does what feisty say about the vpy version have anything to do with it ?

mvtools got this little "temporal" parameter that requires a linear frame request, it's incompatible with multi threading and got removed in the VS versions (both jackoneill's and mine)
Maybe it was on in ur avs mt mess and got the shit all fucked up
https://forum.doom9.org/showthread.php?p=1813996#post1813996

The error message I got when testing the one in post 359 seemed related, something about threading incompatible blah blah. Sorry I don't have the exact error message right now. The vpy version didn't crash with the same settings

If so, would it be a better approach to modify mvtools-pfmod and use the settings without restrictions ? Is it even possible and what would be the pros/cons of doing it ? eg Would it "break" other things?

[MysteryX]

MvTools2 has bugs to fix but Pinterf is on holidays still for the next 2 weeks and you won't hear from him until then

[MysteryX]

From what I understand, SAD calculation is central to MvTools2. It takes a large amount of data in, does a very linear processing, and returns only the sum.

This is where GPU processing would excel! Especially with DCT=1. If anyone wants to take that as a project.

[burfadel]

To overcome transfer inefficiency the more done on the GPU before the transfer back the better. More like transfer to GPU, series of commands, transfer back.

PinterF, any chance of porting over the 'STAR' search method from x265 (it itself ported). It has the effectiveness of exhaustive search and is about as fast as UMH, sometimes faster. Additionally it may not even be optimised to it's full extent in AVX, AVX2 etc, so x265 could potentially benefit as well.

[MysteryX]

Is SVPFlow1 (https://www.svp-team.com/wiki/Manual:SVPflow)'s source code available somewhere? If someone wants to look into adding some GPU acceleration, using code from that library would be a good place to start -- but I can't find it anywhere.

[MysteryX]

Linking to some bugs here (https://forum.doom9.org/showthread.php?p=1816184#post1816184)

[MysteryX]

Here's the source code of SVPFlow1 which uses GPU acceleration
https://www.svp-team.com/files/gpl/svpflow1-src.zip

[pinterf]

Does DCT=1 have the same issues with BlkSize=8 that doesn't use FFTW?


ColorBarsHD()
ConvertToYV12()
jm_fps()
Prefetch(8)

function jm_fps(clip source, float "fps")
{
fps = default(fps, 60)
fps_num = int(fps * 1000)
fps_den = 1000

prefiltered = RemoveGrain(source, 22)
super = MSuper(source, hpad = 16, vpad = 16, levels = 1) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad = 16, vpad = 16) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize = 8, overlap = 4, search = 3, dct = 1)
forward = MAnalyse(superfilt, isb = false, blksize = 8, overlap = 4, search = 3, dct = 1)
forward_re = MRecalculate(super, forward, blksize = 4, overlap = 2, thSAD = 100)
backward_re = MRecalculate(super, backward, blksize = 4, overlap = 2, thSAD = 100)
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)

return out
}



Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\SysWOW64\KernelBase.dll
Address: 0x76C3A9F2

WOOPS!!
WOOPS indeed!
Spent a day on this issue. Thanks for the script, the memory exception appeared immediately. After catching the exception, it turned out that a non-valid motion vector resulted in a memory read past the bottom line of the frame. What? Nonzero motion vectors for a static colorbar clip? Finally it turned out that in mt mode sometimes real motion vectors were generated, even for a blank black clip.

The problem is that the assembly code that calculates integer dct for 8x8 block sizes is _not_ thread safe. It has a single internal buffer of 8x8 words and there is a possibility that the threads are using it parallelly, thus messing up the internal calculations.

At least this is my assumption. Providing a new buffer parameter for this assembly routine (different one for each filter instance), the problem disappeared and the results became consistent (same input -> same output).

[GMJCZP]

Hello pinterf, what happened to what I put in the post #353. Thanks.

[pinterf]

Hello pinterf, what happened to what I put in the post #353. Thanks.
"I noticed that the parameter search = 5 (Umh) produces identical results as search = 4 (Hex). In x264 the results are different."
Umh starts with cross search then with a "ring" of radius 4 (or rings with radius 4, 8, ... depending on the search param), and is finally using hex search.

The two methods are different by looking at the code, though there is a comment saying that "// my mod: do not shift the center after Cross"

[MysteryX]

Welcome back! Perhaps you could look into the "MRecalculate: wrong pixel type" error I'm getting when combining FRC with mClean as a priority? This one should be easy to fix and is blocking me

[GMJCZP]

Umh starts with cross search then with a "ring" of radius 4 (or rings with radius 4, 8, ... depending on the search param), and is finally using hex search.

The two methods are different by looking at the code, though there is a comment saying that "// my mod: do not shift the center after Cross"

What? :confused:

[MysteryX]

It seems MvTools2 is the plugin everybody uses yet nobody understands and nobody wants to fix. There are tons of bugs that have been there since the start and that were never fixed.

As for MT issues with DCT=1, the VapourSynth version works perfectly fine so the ff3d library isn't responsible for the issues.

[pinterf]

It seems MvTools2 is the plugin everybody uses yet nobody understands and nobody wants to fix. There are tons of bugs that have been there since the start and that were never fixed.
Good. You can start fixing those tons of bugs... If you want, of course.

[MysteryX]

Good. You can start fixing those tons of bugs... If you want, of course.
I tried but gave up before getting local compilation to work.

[pinterf]

Back-from-the-holiday edition.

Download MvTools2 2.7.22 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.22)

- 2.7.22 (20170830)
Misc: Stop using version suffix .22
Fix: [DCT 8x8@8bit] garbage on x64: internal assembly code did not save xmm6/xmm7
Fix: [DCT 8x8@8bit] safe multithreading for integer DCT (8x8 block size, 8 bit video): assembly had a single working buffer.
Fix: [MDegrain] did not release input motion vector clips in destructor, possible hang at script closing. Bug since 2.7.1.22 (introducing MDegrain4/5)
Mod: fftw conversion constant of sqrt(2)/2 is more accurate (was:0.707), 16 bit formats may benefit (by feisty2)
Fix: SSE4 assembly instructions in x64, broke on non-SSE4 processors

This release fixes some ancient issues.

Multithreaded scripts using the integer DCT path (8x8 block size, 8 bits) now are producing identical results for each runs. Sor far they were different because of the single common internal buffer, which got overwritten and used by different threads simultaneously. With special input clips (like ColorbarsHD) it resulted in access violation. Thanks for MysteryX for the report and the script.

After an analysis with integer dct, the x64 version is now giving the same result as the 32-bit version. Previously it was different and wrong, because the assembly code did not save xmm6 and xmm7 registers, which is compulsory on x64. This one was a very hard-to-find problems.

[yup]

pinterf :thanks: for update.
Now some my scripts work stable.
But I see strange behaviour when open scripts in VirtualDubMod, I do not see error message if I writen script with error related to MVTools functions, during this VirtatualDub hung and not response.
I can not close video in Vitualdub, only close Vitualdub.
Job control also do not work.
Please advice.

yup.

pinterf :thanks:
With last update issue gone.
yup.

[MysteryX]

Previously it was different and wrong, because the assembly code did not save xmm6 and xmm7 registers, which is compulsory on x64.
:eek:

How much time did you spend on this?

btw did you have time to look at what is causing the weird "MReclaculate: wrong pixel type" error?

[FranceBB]

Thanks for your hard work, really appreciated! :)
Works like a charm in XP x86.

[GMJCZP]

pinterf, I appreciate your efforts. But I still doubt why dct = 4 and dct = 5 produce identical results, and of course with dct=0.

[pinterf]

pinterf, I appreciate your efforts. But I still doubt why dct = 4 and dct = 5 produce identical results, and of course with dct=0.

From an earlier post:
"noticed that the parameter search = 5 (Umh) produces identical results as search = 4 (Hex). In x264 the results are different."

Now I'm confused, dct or search parameter? Or both? Is there any parameter combination that produces different result? Could you help me by posting a script which I can use for testing?

[GMJCZP]

Script as example:

Here (https://forum.doom9.org/showthread.php?p=1813061#post1813061)

Sorry if I was confusing you. It's search and not dct parameter.

If for example, I want to use search= 5 in MRecalculate the result is equal to search =4, which should not be.

[burfadel]

I'm presuming hex and umh are from x264, x265 used those from x264. x265 also has STAR like I mentioned earlier. If you're looking into hex and umh, might be something to consider since it's performance is between hex and umh, but performs like exhaustive.

[real.finder]

So, now, with the latest VapourSynth version of this MVTools, how would one write the Stab script with these new Depans in MVTools? I'm using Staxrip 1.6 x64, VapourSynth filter setup if that helps.


you should post here https://forum.doom9.org/forumdisplay.php?f=82

[tebasuna51]

Lynx_TWO post moved to https://forum.doom9.org/showthread.php?t=174854

[MysteryX]

I'm getting a bunch of issues compiling.

First, YASM v1.3 doesn't work, need to use YASM v1.2 which works.

Then, I got a bunch of errors with mvtools.rc, which maybe is because I'd need to install MFC just for that. I commented the file and it worked.

Debug compilation works, but release gives me this:
cannot open input file 'Win32\Release\mvtools\Bilinear.obj'

Looking into the "MRecalculate: wrong pixel type" error.

First, the error isn't when processing the prefilter clip, but rather, is complaining that MAnalyze on the prefilter returned a different type than what we're trying to re-analyze.

The weird thing is that loading the prefilter with AviSource or LWLibavVideoSource gives a different pixel type.

LWLibavVideoSource gives pixel type -1610612720
AviSource gives pixel type -1610612728

Is there a way to easily know in the debugger what these values represent?

Now I'm testing the latest version of mClean with the latest version of mvtools2 and somehow it's now working as a prefilter. However, performance is atrocious!! (with no MT)


Pref=LWLibavVideoSource("Pref.avi")
FrameRateConverter(60, preset="slower", Prefilter=Pref)

FPS (min | max | average): 0.113 | 6.759 | 0.541
Memory usage (phys | virt): 1024 | 1031 MiB
Thread count: 27
CPU usage (average): 11%


FrameRateConverter(60, preset="slower", Prefilter=mClean(rn=10))

FPS (cur | min | max | avg): 0.032 | 0.028 | 6.813 | 0.129
Memory usage (phys | virt): 1099 | 1175 MiB
Thread count: 21
CPU usage (current | average): 12% | 12%

[Groucho2004]

Then, I got a bunch of errors with mvtools.rc, which maybe is because I'd need to install MFC just for that. I commented the file and it worked.
You should only need winres.h and of course the rc compiler which is part of the platform SDK. Make sure you have the SDK installed and the environment set up.

Edit: I see that the .rc file does include "afxres.h". Simplify the file like this:
#include <winres.h>

VS_VERSION_INFO VERSIONINFO
FILEVERSION 2,6,0,5
PRODUCTVERSION 2,6,0,5
FILEOS VOS_NT
FILETYPE VFT_DLL
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904b0"
BEGIN
VALUE "Comments", "Motion estimation and compensation"
VALUE "CompanyName", "A.G.Balakhnin aka Fizick, fizick@avisynth.org.ru"
VALUE "FileDescription", "MVTools plugin for AviSynth "
VALUE "FileVersion", "2.6.0.5"
VALUE "InternalName", "mvtools"
VALUE "LegalCopyright", "2004 Manao, 2005 Fizick, 2008 TSchniede under GNU GPL v2"
VALUE "OriginalFilename", "mvtools.dll"
VALUE "ProductName", "mvtools"
VALUE "ProductVersion", "2, 6, 0, 5"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 1200
END
END


Alternatively, try this (https://stackoverflow.com/questions/35436654/cant-open-resource-file-in-vs-2015-cant-open-include-file-afxres-h).

LWLibavVideoSource gives pixel type -1610612720
AviSource gives pixel type -1610612728

Is there a way to easily know in the debugger what these values represent?
From avisynth.h:
// YV12 must be 0xA000008 2.5 Baked API will see all new planar as YV12
// I420 must be 0xA000010

-1610612720 = 0xA000010 = i420
-1610612728 = 0xA000008 = YV12

[MysteryX]

-1610612720 = 0xA000010 = i420
-1610612728 = 0xA000008 = YV12
What's the difference between YV12 and I420?

mClean takes 20 minutes to encode.
FrameRateConverter(preset="slower") takes 3 hours on a 3 minutes 1080p clip

FrameRateConverter(preset="slower", prefilter=mClean(rn=10)) now does work (Pinterf, did you change something here?) but... with 4 instances, it would take at least 22 hours of work!! if it ever finishes

I tried running the prefilter into a separate script and loading it with AviSource. Then I get again "MRecalculate: wrong pixel type"

This script, however, works. (but SLOW and taking a LOT of memory!!)

LWLibavVideoSource("Preview.avi", cache=False)
AudioDub(LWLibavAudioSource("Preview.avi", cache=False))
Pref=AviSource("PreviewPref.avs")
ConvertToYV16().ConvertToYV12()
FrameRateConverter(NewNum=60, NewDen=1, Preset="slower", prefilter=Pref)


In terms of debugging, I wouldn't even know where to look.

[Groucho2004]

What's the difference between YV12 and I420?
Why don't you just search for YV12/i420 in avisynth.h and see how the values are constructed?
I think this is the main difference:
CS_VPlaneFirst = 1 << 3, // YV12, YV16, YV24, YV411, YUV9
CS_UPlaneFirst = 1 << 4, // I420
...
...
CS_YV12 = CS_GENERIC_YUV420 | CS_Sample_Bits_8, // YVU 4:2:0 planar
CS_I420 = CS_PLANAR | CS_YUV | CS_Sample_Bits_8 | CS_UPlaneFirst | CS_Sub_Height_2 | CS_Sub_Width_2, // YUV 4:2:0 planar

[MysteryX]

uh... the difference is YVU vs YUV !? so something along the chain isn't handling that right. It could be anywhere though.

This bug started happening when converting the prefilter to 16-bit and then back to 8-bit.

Then it has been partially resolved in the latest version of MvTools (?)

[TheFluff]

People being overly specific and comparing format constants directly when they should be using IsYV12() has a long history in Avisynth. It's extremely rarely for filters to treat U and V differently so most filters don't need to know the plane order. I wrote this Avisynth wiki page (http://avisynth.nl/index.php/I420) a long time ago because I got annoyed about people repeating the same mistake.

You can try SwapUV if you want to try a workaround, but I'm unsure if that swaps the format constant or the actual plane pointers.

[MysteryX]

Yeah I was thinking of Swap, but then it's "working" with the latest version, in most cases. In the code, IsYV12 wouldn't work because it's comparing whether the format being recalculated is the same format that was analyzed, thus it compares both constants.

I just tried this code and it's working. I get a stable 0.333fps on a single instance.


P="Encoder\"
LoadPlugin(P+"MP_Pipeline.dll")
SetMemoryMax(1)

MP_Pipeline("""
### inherit start ###
P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"MvTools2.dll")
LoadPlugin(P+"MaskTools2.dll")
LoadPlugin(P+"FFT3DFilter.dll")
LoadPlugin(P+"ModPlus.dll")
LoadPlugin(P+"RgTools.dll")
LoadPlugin(P+"DCTFilter.dll")
Import(P+"MClean.avsi")
Import(P+"FrameRateConverter.avsi")
LoadPlugin(P+"FrameRateConverter.dll")
file="Like a Cat.mp4"
### inherit end ###

LWLibavVideoSource(file, cache=False)
MClean(rn=10)
### prefetch: 2, 2
### ###

Pref=last
LWLibavVideoSource(file, cache=False)
FrameRateConverter(60, preset="slower", Prefilter=Pref)
### prefetch: 2, 2
### ###
""")

AudioDub(LWLibavAudioSource(file, cache=False))


However, running this over 4 instances gives still unreasonable performance, perhaps because I'm running out of memory with 8GB. I get 0.6fps giving an encoding time of 9h.

The only thing that works well if I want to use mClean as a prefilter is to first encode into an AVI and then reload that into the main script.

[MysteryX]

I just realized something.

I have this video
Video: MPEG4 Video (H264) 1920x1080 25fps 3268kbps [V: h264 high L4.0, yuv420p, 1920x1080, 3268 kb/s]

After encoding with FrameRateConverter it became
Video: I420 1920x1080 60fps [V: rawvideo, yuv420p, 1920x1080]

This means the output of MFlowFps is mistakenly I420 instead of YV12, and when that's being re-fed as input for another round of MAnalyze/MRecalculate, that causes a format mismatch.

[Groucho2004]

I just realized something.

I have this video
Video: MPEG4 Video (H264) 1920x1080 25fps 3268kbps [V: h264 high L4.0, yuv420p, 1920x1080, 3268 kb/s]

After encoding with FrameRateConverter it became
Video: I420 1920x1080 60fps [V: rawvideo, yuv420p, 1920x1080]

This means the output of MFlowFps is mistakenly I420 instead of YV12, and when that's being re-fed as input for another round of MAnalyze/MRecalculate, that causes a format mismatch.
I don't know what "encoding with FrameRateConverter" means but you can easily check the returned color space of a script with AVSMeter. It has the correct mappings of returned values according to the latest AVS+ header.

[pinterf]

The output format of MFlowFps should be the same as of the input clip.

[burfadel]

There seems to be a bug in MScaleVect that causes a shift to the left, as reported by MysteryX in mClean v1.8. I didn't notice it before because I wasn't looking for it, but I can see now! It isn't related to blocksize or other settings, and even the simplest of uses. It affects areas of motion more which makes sense, and is only slight, but problematic when not doing chroma processing or doing chroma processing separately. I'm guessing it may also fractionally affect picture fidelity.

Basic example:
blksize=16
blksizeV=16
overlap=4
overlapV=4

super = MSuper (hpad=16, vpad=16)
supersc = MSuper(BicubicResize(Width/2, Height/2), hpad=16/2, vpad=16/2)

bvec2 = MAnalyse (supersc, isb = true, delta = 2, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2)
bvec1 = MAnalyse (super, isb = true, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV)
fvec1 = MAnalyse (super, isb = false, delta = 1, blksize=blksize, blksizeV=blksizeV, overlap=overlap, overlapV=overlapV)
fvec2 = MAnalyse (supersc, isb = false, delta = 2, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2)

bvec2 = MscaleVect (bvec2, 2)
fvec2 = MscaleVect (fvec2, 2)

Mdegrain2(super, bvec2, bvec1, fvec1, fvec2)

It also occurs if you use MScaleVect right through:
blksize=16
blksizeV=16
overlap=4
overlapV=4

super = MSuper (hpad=16, vpad=16)
supersc = MSuper(BicubicResize(Width/2, Height/2), hpad=16/2, vpad=16/2)

bvec2 = MAnalyse (supersc, isb = true, delta = 2, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2)
bvec1 = MAnalyse (supersc, isb = true, delta = 1, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2)
fvec1 = MAnalyse (supersc, isb = false, delta = 1, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2)
fvec2 = MAnalyse (supersc, isb = false, delta = 2, blksize=blksize/2, blksizeV=blksizeV/2, overlap=overlap/2, overlapV=overlapV/2)

bvec2 = MscaleVect (bvec2, 2)
bvec1 = MscaleVect (bvec1, 2)
fvec1 = MscaleVect (fvec1, 2)
fvec2 = MscaleVect (fvec2, 2)

Mdegrain2(super, bvec2, bvec1, fvec1, fvec2)

This would affect all functions that use MScaleVect, which is why it probably doesn't work very well with MFlowFPS.

[pinterf]

There seems to be a bug in MScaleVect that causes a shift to the left, as reported by MysteryX in mClean v1.8. I didn't notice it before because I wasn't looking for it, but I can see now! It isn't related to blocksize or other settings, and even the simplest of uses. It affects areas of motion more which makes sense, and is only slight, but problematic when not doing chroma processing or doing chroma processing separately. I'm guessing it may also fractionally affect picture fidelity.
I have checked the source (https://github.com/pinterf/mvtools/blob/mvtools-pfmod/Sources/MScaleVect.cpp#L162), vectors are scaled with multiplication by the factor, add 0.5 as rounding, then casted back to integer.

Just an idea:

Casting to integer simply strips the decimal part off, but I think the rounder value should should be -0.5 when x or y part of the vector is negative
(x,y) = (2,3) -> (2*2+0.5, 3*2 + 0.5) -> (4.5, 6.5) -> (4,6)
(x,y) = (-2,-3) -> (-2*2+0.5, -3*2 + 0.5) -> (-3.5, -5.5) -> (-3,-5)

Obviously the results for negative vector components are incorrect.
-1 scaled by 2 remains -1
-2 scaled by 2 is -3, etc...

I don't know if the shifts you are experiencing can be explained by this logic, but anyway, I can build a test version and provide a link to you.