MVTools-pfmod

[MysteryX]

Originally Posted by pinterf

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

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]

Originally Posted by 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.

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

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]

Originally Posted by Lynx_TWO

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]

Originally Posted by MysteryX

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.

Originally Posted by MysteryX

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]

Originally Posted by Groucho2004

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

Originally Posted by MysteryX

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

Originally Posted by 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.

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]

Originally Posted by 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.

I have checked the source, 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.