MVTools-pfmod

[Morku]

EDIT: found it, fix is coming soon

Thanks a lot :)

[pinterf]

New release with an important fix (regression in previous 2.7.16.22), big thanks to Morku for the early report.

The SAD mask scaling issue (different magnitude for YV12 and YV24) was noticed by MysteryX. @MysteryX: please have a look at it.

MvTools2 2.7.17.22 (https://github.com/pinterf/mvtools/releases/tag/2.7.17.22)

Change log
- 2.7.17.22 (20170426)
Fix: Regression in 2.7.16.22: MDegrain right pixel artifacts on non-modulo 16 widths
Misc: MMask, mode SADMask output is normalized further by video subsampling (YV16/YV24 has larger SAD value due to bigger chroma part that classic YV12)

[MysteryX]

YV24 masks are now weaker than YV12 masks.

YV12 / YV24
https://s12.postimg.org/3tq0khpa1/Mask_YV12.png (https://postimg.org/image/3tq0khpa1/) https://s12.postimg.org/e52dd5gzd/Mask_YV24.png (https://postimg.org/image/e52dd5gzd/)

It seems you're over-compensating.

[Taurus]

Thanks pinterf!
The same thing Morku was explaining happened to me yesterday.
I hope the new build will fix this.
It happened on a cropped and resized video to 960x720.
Straight 1920x1080 and 1280x720 do not show this artifact.
Will test the new build in a few minutes...
Hmmh, at first glance everything is allright now.
Green line and grey line after cropping are gone on my side.
Maybe Morku can comment on this.

QTGMC 3.357s
masktools2 2.2.7
nnedi3 0.9.4.40
rgtools 0.95
dfftest 1.94 ICL10
mvtools2 2.7.17.22

[pinterf]

YV24 masks are now weaker than YV12 masks.[/img][/url]

It seems you're over-compensating.
Or the theory fails.
SAD comes from luma and chroma
On YV12 Y:U:V has 1:0.25:0.25 ratio
On YV24 the ratio is 1:1:1.
I think the masks should look the same when you convert the clips to greyscale before analysis (or chroma=false)? Just an idea.

[pinterf]

Thanks pinterf!
The same thing Morku was explaining happened to me yesterday.

Uh, I'm really sorry for the inconvenience.

[Morku]

Green line and grey line after cropping are gone on my side.
Maybe Morku can comment on this.


My example also looks fine now without cropping and resizing.
Thank you for the fast fix.

[Taurus]

Uh, I'm really sorry for the inconvenience.

No problem.
I deeply appreciate your work on modernising and fixing Avisynth flaws:thanks:.

[MysteryX]

I think the masks should look the same when you convert the clips to greyscale before analysis (or chroma=false)? Just an idea.
Just to clarify, the screenshots call ConvertToY8 on the masks.

[pinterf]

Just to clarify, the screenshots call ConvertToY8 on the masks.
That's ok, I wondered that what happens when the clip to analyze is GreyScale()'d before that. Thus the chroma SAD difference is zero for both YV12 and YV24 and does not affect the SAD weighting.

I'm thinking that there should be an option to be able to give weight the chroma part of the SAD. The internal contribution of SAD elements (Luma:Chroma) in YV12 is 1:0.5, while for YV24 the ratio is 1:2, which drives the whole thing a bit off.

[MysteryX]

Here's our famous moose in Y8 / Y12 / Y16 / Y24
https://s12.postimg.org/8azyfqv89/Mask_Y8.png (https://postimg.org/image/8azyfqv89/) https://s12.postimg.org/x5jg9tg2h/Mask_Y12.png (https://postimg.org/image/x5jg9tg2h/) https://s12.postimg.org/lhpef9qxl/Mask_Y16.png (https://postimg.org/image/lhpef9qxl/) https://s12.postimg.org/jr6dds9eh/Mask_Y24.png (https://postimg.org/image/jr6dds9eh/)

[MysteryX]

Question about MMask. According to doc

Creates mask clip from source clip with motion vectors data. Mask is defined by blocks data, but is interpolated to fit full frame size. The mask is created both on the luma and on chroma planes. Mask values may be from 0 (min) to 255 (max).


In practice, I found chroma to contain rubbish and I'm only using the Luma plane. Yet the docs seem to say otherwise.

[MysteryX]

Pinterf, are you going to do additional modification to MMask?

From my tests, with your latest version, YV24 is about 1.25x stronger than YV12. If I want to adjust manually, however, that adjustment would need to be done before applying gamma, which means I couldn't use the Gamma argument and would instead have to use Levels after.

[MysteryX]

I realized mask strength is also different between BlkSize=8 (weaker), 16, and 32 (stronger).

I'm just curious as to what causes such mask strength variation. It's hard to work with the masks if their levels vary based on various factors.

[MysteryX]

MvTools only supports block size 4, 8, 16 and 32, while SVP supports 10, 12, 14, etc. Would it be difficult to give more flexibility for block size?

[pinterf]

MvTools only supports block size 4, 8, 16 and 32, while SVP supports 10, 12, 14, etc. Would it be difficult to give more flexibility for block size?
Yes, a bit difficult, it would need additional SAD asm functions, supporting half (YV12 chroma) and semi-half (YV16 chroma) sizes, MDegrain, etc...

I think making SAD chroma part to have the same well-behaving Luma:Chroma 4:2 ratio is more important. It should give similar results for both for YV12 (as now) and for YV24. Because now YV24 has Luma:Chroma 4:8 ratio inside the block SADs which may over-empasise chroma SAD and may not be desirable. Perhaps an extra chroma SAD scaling factor would enable us to achieve 4:4 or 4:8 luma:chroma SAD ratios.

[MysteryX]

Yes, that's important. Keep us posted.

I'm also curious as to how other scripts were affected by this mask irregularity. SMDegrain script must be affected by this as well.

[pinterf]

New release.
MvTools2 2.7.18.22 (https://github.com/pinterf/mvtools/releases/tag/2.7.18.22)

This release took quite a lot of time, feedback welcomed.

Change log

- 2.7.18.22 (20170512)
Fix: 10-16 bit: DCT buffer possible overflow

Fix: DCT is fast again for non 8x8 blocksizes. Regression since 2.7.5.22.

New: Chroma SAD is now always half of luma SAD, regardless of video format
Without this: YV24's luma:chroma SAD ratio is 4:8 instead of 4:2 (of YV12)

New: MAnalyze, MRecalculate new parameter: "scaleCSAD" integer, default 0
Fine tune chroma SAD weight relative to luma SAD.
ScaleCSAD values for luma:chroma SAD ratio
-2: 4:0.5
-1: 4:1
0: 4:2 (default, same as the native ratio for YV12)
1: 4:4
2: 4:8

New: Block sizes 64, 48, 24, 12, 6
MAnalyze/MRecalculate new block sizes (SATD support mod4 sizes)
List of available block sizes
64x64, 64x48, 64x32, 64x16
48x64, 48x48, 48x24, 48x12
32x64, 32x32, 32x24, 32x16, 32x8
24x48, 24x24, 24x32, 24x12, 24x6
16x64, 16x32, 16x16, 16x12, 16x8, 16x4, 16x2
12x48, 12x24, 12x16, 12x12, 12x6
8x32, 8x16, 8x8, 8x4, 8x2, 8x1
6x24, 6x12, 6x6, 6x3
4x8, 4x4, 4x2
3x6, 3x3
2x4, 2x2

Note: some smaller block sizes can only be available in 4:4:4 formats, due to block size division (chroma subsampling)

New: All block sizes are supported in MDegrain1-6, MDegrainN, and MScaleVect

New: Changed to 2017 version of asm files for 8 bit SAD/SATD functions from x265 project.
Added not implemented asm code for 12, 24, 48 sizes
For some block sizes AVX2 and SSE4 is supported (AVX2 if reported under AviSynth+)
e.g. BlkSize 32 is faster now.

New: MMask SAD Mask to give identical weights for other-than-YV12 formats, e.g. for YV24

[Motenai Yoda]

did you got time to check depan/depanestimate?

[StainlessS]

:thanks: for the update, you are a one man tsunami !
And thank you for being Pinterf :)

[pinterf]

did you got time to check depan/depanestimate?
No, but now i'm investigating. Are you using 32 or 64 bit version?

[MysteryX]

MRecalculate with blksize=3


MVTools: no BLITCHROMA function for block size 1x1

[pinterf]

Int(3/2)=1

[pinterf]

Int(3/2)=1
Edit: try yv24. That's why I've noted above that specific block sizes are unavailable in color spaces with chroma subsampling. 6x6 needs also 3x3 in yv12 and 3x6 in yv16. 3x3 has no further division.

[MysteryX]

I note that masks are still slightly stronger with larger block sizes than with smaller block sizes. Why is that?

[pinterf]

Masks are calculated for blocks. Less blocks, more blocky enlargement. Since they are resized to the original size of the clip. Could a denser overlap help probably?

[MysteryX]

The output isn't necessarily worse; in fact the result can often be better. It's just that the mask is stronger too so I have no way of knowing which is better through code.

Here's an example.

Frame in 16 / 32
https://s29.postimg.org/gho8f26fn/Flow16.png (https://postimg.org/image/gho8f26fn/) https://s29.postimg.org/k2k3yaaz7/Flow32.png (https://postimg.org/image/k2k3yaaz7/)

Mask in 16 / 32
https://s29.postimg.org/ajaf4tngz/Mask16.png (https://postimg.org/image/ajaf4tngz/) https://s29.postimg.org/cp4pzbqxf/Mask32.png (https://postimg.org/image/cp4pzbqxf/)

Although the image looks better in 32, the mask is also considerably stronger in 32.

Masks vary between frames, but it has a strong tendency for the mask to be stronger with larger block size, without regards to the actual output quality.

[real.finder]

I wonder if mvtools need scaleparams Parameter since the output is different for every bit depth (like what tormento note in encode size (https://forum.doom9.org/showthread.php?t=169832&page=11))

[pinterf]

What parameter? Sad is already normalized to 8x8 8 bit, taking into account subsampling, block size and bit depth. Scene change value perhaps in MSCDetection?

[real.finder]

What parameter? Sad is already normalized to 8x8 8 bit, taking into account subsampling, block size and bit depth. Scene change value perhaps in MSCDetection?

Ysc? now it be the max value by default, right? I didn't note any script that use some other value, so if it use max value by default then I see no problem

I was wonder about something else that may used in SMDegrain and QTGMC

[pinterf]

And that parameter is scaled, anyway, when given

[pinterf]

New release, mask fixes after a painful debug session.
Important fix for DepanEstimate (thanks to Motenai Yoda)
And some new features again.

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

- 2.7.19.22 (20170525)
New: [MMask] Support any 8-16 bits greyscale and planar input video formats (Y8..Y16, Planar RGB)
Input clip can even be of different bit depth or format from vector's original format
For kind==5 where U and V is filled, the greyscale option is not allowed
Mod: [MMask] Faster: request source frame only for kind=5.
Fix: [MxxxxFPS,MMask]: MakeVectorOcclusionMaskTime garbage in bottom blocks (30 hrs of debugging)
Fix: [MMask] bottom padding garbage for padded frame dimension
Fix: [MMask] proper 10+ bits scene change values (for default: 1023, 4095, 16383, 65535. Was: 65535)
Parameter is still in 8-bit range
Fix: [MRecalculate] prevent overflow during thSAD scaling in 16 bits or large block sizes (32, 48...)
Fix: [DepanEstimate] Sometimes giving wrong motion instead of scene change detection
Fix: [MAnalyze] Possible overflow in MAnalyze 8 bit, block size 48x48 and above.
Overflow-safe predictor recalc for big block sizes
New: [General] Add block size 12x3 for SAD, allow 6x24
List of available block sizes
64x64, 64x48, 64x32, 64x16
48x64, 48x48, 48x24, 48x12
32x64, 32x32, 32x24, 32x16, 32x8
24x48, 24x24, 24x32, 24x12, 24x6
16x64, 16x32, 16x16, 16x12, 16x8, 16x4, 16x2
12x48, 12x24, 12x16, 12x12, 12x6, 12x3
8x32, 8x16, 8x8, 8x4, 8x2, 8x1
6x24, 6x12, 6x6, 6x3
4x8, 4x4, 4x2
3x6, 3x3
2x4, 2x2
Mod: [Internal] Reorganized 10-16 bit SAD simd intrinsics, faster 8-12% for BlkSize 12-32


Fixed an old bug in a mask helper function.

The bug which happened to emerge _somewhere_ in the flow of the frame rate converter script by MysteryX et al., only in multithreading, only with special frame size and block and overlaps dimensions, and can could only be recognized by running the same encoding six times and check the one or two different sized result mkv frame by frame.

Finally replacing the pitch variable (https://github.com/pinterf/mvtools/commit/ad11ad0878e4a49acfc0fa065e20a7fca853eae9) solved the mistery (uninitialized mask block buffer part which contained some garbage from other thread's frame buffer). Never again this madness, I'm getting tired.

Then fixed another bottom part padding garbage issue which worked when Avisynth+ used asm bitBlt instead of memcpy BitBlt. The old code relied on Avisynth doing BitBlt copy from bottom to top vs top to bottom.

[burfadel]

I just tried 2.7.19.22 which results in an instant crash (x64 version). Version 2.7.17.22 works fine. I notice Version 2.7.19.22 files are very much noticeably bigger than 2.7.17.22.

[MysteryX]

Never again this madness, I'm getting tired.
MaskFun.cpp, you might want to rename that

[pinterf]

I just tried 2.7.19.22 which results in an instant crash (x64 version). Version 2.7.17.22 works fine. I notice Version 2.7.19.22 files are very much noticeably bigger than 2.7.17.22.
Bad news. Which filters/script were you using? I probably need your processor family as well, thanks.
Bigger file sizes are normal and come from the huge increase in block sizes.

[burfadel]

Bad news. Which filters/script were you using? I probably need your processor family as well, thanks.
Bigger file sizes are normal and come from the huge increase in block sizes.

MysteryX's Framerateconverter, the 24 May 2017 version. This is on a Ryzen R7-1700X CPU.

Not sure what part of the code, some basic scripts like filldrops3 works, as does jm_fps for which frameconverter is based upon. If I set output="none" in framerateconverter it still crashes.

BTW the x64 dll for 2.7.17.22 is 1.28 MB, and for 2.7.19.22 it is 3.04 MB, so almost 238 percent larger. Does that sound right?

[jackoneill]

Fixed an old bug in a mask helper function.

The bug which happened to emerge _somewhere_ in the flow of the frame rate converter script by MysteryX et al., only in multithreading, only with special frame size and block and overlaps dimensions, and can could only be recognized by running the same encoding six times and check the one or two different sized result mkv frame by frame.

Finally replacing the pitch variable (https://github.com/pinterf/mvtools/commit/ad11ad0878e4a49acfc0fa065e20a7fca853eae9) solved the mistery (uninitialized mask block buffer part which contained some garbage from other thread's frame buffer). Never again this madness, I'm getting tired.


The extra funny thing is that I fixed this very bug in the VapourSynth port over a year ago (https://github.com/dubhater/vapoursynth-mvtools/commit/6e78a6e74a31b867348b0046613f41df78a4d692). I remember telling Firesledge about it, but I guess he fixed it after you forked.

[pinterf]

The extra funny thing is that I fixed this very bug in the VapourSynth port over a year ago (https://github.com/dubhater/vapoursynth-mvtools/commit/6e78a6e74a31b867348b0046613f41df78a4d692). I remember telling Firesledge about it, but I guess he fixed it after you forked.
Omg, sometimes I go over your commit list, but I missed this one. (There was no update after 2.6.0.5 which was my initial source)

And there were other obstacles detecting this bug, such as at the very beginning I put MFlowFPS in Serialized MT mode for avs+ and was trying to debug in this setup. Which was not a good idea as this mode is not working properly, I have just written in avs+ topic.

[burfadel]

Pinterf, not sure what causes that instant crash bug. Like I said, other simpler scripts work, so I believe it must be a change related to the more complex functions of the script.

[pinterf]

Pinterf, not sure what causes that instant crash bug. Like I said, other simpler scripts work, so I believe it must be a change related to the more complex functions of the script.
Thanks, it happens when exiting from the DLL, MMask+greyscale input clip. Filter wants to release things related to chroma, which wasn't allocated.
Now I have another AV but it may be related to the current Framerateconverter.dll, but I have to make sure.
EDIT: recompiled Framerateconverter with VS2015 solved the problem, maybe I had no VS 2017 redist installed (? I have VS2017 on my machine)
EDIT2: there are still occasional crashes when running this converter script, but it does not seem to be mvtools2 related.

[pinterf]

Hotfix (MMask causing crash when DLL exits), thanks burfadel for the report!

Download: MvTools2 2.7.20.22 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.20.22)
As usual, please report any issue, for there were big internal changes since 2.7.17.22, so there can be bugs. Thanks.

And here is a note: MMask earlier somehow accepted Y8 input, but still processed all three planes with the internal resizing. But since the pitch is zero, it happened to spoil only the top line of the already filled Y plane (for YV12: half of it), to tell the truth, I don't know why it did not crash, but anyway, template clip format is free now (8-16, 4:2:0, 4:4:4, planar RGB, Y-only). And for greyscale the filter don't spend time with preparing and copying masks for non-existant U and V planes. (The reason of the hotfix was that although a resizer object was not created for U/V planes but it still got freed up)

Change log
- 2.7.20.22 (20170526) - hotfix
Fix: [MMask] greyscale input resulted in AV when filter exiting

- 2.7.19.22 (20170525)
New: [MMask] Support any planar input video formats e.g. greyscale, Planar RGB.
Input clip can even be of different bit depth or format from vector's original format
For kind==5 where U and V is filled, the greyscale option is not allowed
Mod: [MMask] Faster: request source frame only for kind=5.
Fix: [MxxxxFPS,MMask]: MakeVectorOcclusionMaskTime garbage in bottom blocks (30 hrs of debugging)
Fix: [MMask] bottom padding garbage for padded frame dimension
Fix: [MMask] proper 10+ bits scene change values (for default: 1023, 4095, 16383, 65535. Was: 65535)
Parameter is still in 8-bit range
Fix: [MRecalculate] prevent overflow during thSAD scaling in 16 bits or large block sizes (32, 48...)
Fix: [DepanEstimate] Sometimes giving wrong motion instead of scene change detection
Fix: [MAnalyze] Possible overflow in MAnalyze 8 bit, block size 48x48 and above.
Overflow-safe predictor recalc for big block sizes
New: [General] Add block size 12x3 for SAD, allow 6x24
List of available block sizes
64x64, 64x48, 64x32, 64x16
48x64, 48x48, 48x24, 48x12
32x64, 32x32, 32x24, 32x16, 32x8
24x48, 24x24, 24x32, 24x12, 24x6
16x64, 16x32, 16x16, 16x12, 16x8, 16x4, 16x2
12x48, 12x24, 12x16, 12x12, 12x6, 12x3
8x32, 8x16, 8x8, 8x4, 8x2, 8x1
6x24, 6x12, 6x6, 6x3
4x8, 4x4, 4x2
3x6, 3x3
2x4, 2x2
Mod: [Internal] Reorganized 10-16 bit SAD simd intrinsics, faster 8-12% for BlkSize 12-32

[burfadel]

Thanks! Works well now :).

[hello_hello]

pinterf,
In case you'd care to take a look at it, there appears to be a problem with your flavour of MaskTools2 and the SeeSaw sharpening script.
https://forum.doom9.org/showthread.php?p=1808548#post1808548

Thanks.

Hi, I have tried the new version of masktools and there is a problem

Evaluate: Unhandled C++ exception!

(SeeSaw.avs, line 128)

(SeeSaw.avs, line 80)

[burfadel]

pinterf,
In case you'd care to take a look at it, there appears to be a problem with your flavour of MaskTools2 and the SeeSaw sharpening script.
https://forum.doom9.org/showthread.php?p=1808548#post1808548

Thanks.

Try combining it with lsfmod (for example) to initiate a crash.

[hello_hello]

Try combining it with lsfmod (for example) to initiate a crash.

No problems with LSFMod here (default settings). I use LSFMod quite regularly.

Although if you mean like this it's still the same error:

a = last
b = a.LSFMod()
SeeSaw(a, b)

I just realised I posted in the wrong thread (MVTools2 rather than MaskTools2) so I'll copy my post above to that thread.
https://forum.doom9.org/showthread.php?p=1808558#post1808558

[burfadel]

No problems with LSFMod here (default settings). I use LSFMod quite regularly.

Although if you mean like this it's still the same error:

a = last
b = a.LSFMod()
SeeSaw(a, b)

I just realised I posted in the wrong thread (MVTools2 rather than MaskTools2) so I'll copy my post above to that thread.
https://forum.doom9.org/showthread.php?p=1808558#post1808558

What I meant was, seesaw() for me works by itself, but when there are certain other filters somewhere else in the script it fails. It's possibly a multi-instance issue calling on the same filters.

Does it work by itself with nothing else in the script? If so, try enabling the filters until it fails. If my above assumption is correct (because it is for me), it will fail when you use another script/plugin that uses masktools.

[hello_hello]

pinterf,
due to a discussion in this thread (https://forum.doom9.org/showthread.php?p=1810228#post1810228) regarding possible plugin differences, I tested a few versions of MVTools2 (Avisynth 2.6 on XP) and thought I'd ask about the result.

I was using Avisynth's Compare() as per the following pic (QTGMC deinterlacing), because when viewing the raw Avisynth output it looks visually identical to me, but there must be enough differences when different versions of MVTools2 are used to cause the video to be encoded slightly differently, as after it's encoded I can see it's not the same. Not necessarily better or worse, but there's definitely encoding differences.

How much of it is by accident or design or by bug fix, I don't know.

QTGMC 3.33, MVTools2 version 2.7.20.22 vs 2.5.11.22
http://image.ibb.co/eFJPA5/compare2.jpg

With the following script for testing (although I think it'd apply to any script using MVTools2)

DGDecode_mpeg2source("D:\video.d2v")
fields=AssumeTFF().SeparateFields()
super = MSuper(fields)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=2)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=2)
MDegrain1(fields, super, backward_vec2,forward_vec2,thSAD=400)
Weave()

MVTools2 version 2.6.0.5 (cretindesalpes) has a different output to version 2.5.11.22 (Fizick)
Version 2.7.0.1 (1st Pinterf) has identical output to version 2.6.0.5 (cretindesalpes)
Version 2.7.20.22 (latest Pinterf) has a different output to version 2.7.0.1 (1st Pinterf)

By accident, I discovered the following script produces green frames with version 2.7.20.22, but versions 2.7.0.1 and 2.7.0.22d are okay. Anything newer results in green frames.

tr = 6 # Temporal radius
super = MSuper ()
multi_vec = MAnalyse (super, multi=true, delta=tr)
MDegrainN (super, multi_vec, tr, thSAD=400, thSAD2=150)

Version 2.7.0.22d:

http://image.ibb.co/dMMb8Q/2_7_0_22d.jpg

Version 2.7.1.22:

http://image.ibb.co/dOtChk/2_7_1_22.jpg

Version 2.7.20.22:

http://image.ibb.co/cDfEv5/2_7_20_22.jpg

Cheers.

[hello_hello]

While I'm asking, I assume this means there's a reasonable difference between the old ff3dfilter and the new? Is it something to care about?

Cheers.

fft3dfilter 2.3 vs fft3dfilter 2.4

http://image.ibb.co/mGjk2k/fft3dfilter1.jpg

fft3dfilter 2.3 vs fft3dfilter 2.1.1

http://image.ibb.co/cGOdNk/fft3dfilter2.jpg

[pinterf]

I'll check it later this week
EDIT: Found. Seems that since MDegrain4-6 functions exist, no one uses MDegrainN?

[hello_hello]

I think I copied that script from the MVTools2 documentation for testing. If I did it was really just by chance I picked that one.

If the difference in QTGMC output is being caused by MVTools2 it'd be something other than MDegrainN. I'm not sure what it uses or when, but I found mention of MDegrain1, MDegrain2, MDegrain3, MDegrain4 & MDegrain5 in the script, plus these days it gets the SMDegrain script involved too.
(QTGMC 3.357s)

For the above comparison I used QTGMC's default settings. ie QTGMC()
I can try investigating further if you like.

Thanks.