MVTools-pfmod

[real.finder]

Wouldn't the effective block size in the analysis be different between lsb and native 16 bit? If so it will affect processing speed and possibly output quality.

not always

https://forum.doom9.org/showpost.php?p=1827085&postcount=424

and yes motion analysis in 16 is slower

[tormento]

they should be same in the case above
From DGDecNV manual:

fulldepth: true/false (default: false)
When fulldepth=true and the encoded video is HEVC 10-bit or 12-bit, then DGSource() delivers 16-bit data to Avisynth with the unused lower bits zeroed. The reported pixel format is CS_YUV420P16. If either of the two conditions are not met, then DGSource() delivers 8-bit YV12 or I420 data, as determined by the i420 parameter. When fulldepth=false and the video is HEVC 10-bit or 12-bit, then the video is dithered down to 8-bit for delivery. If you need a reduced color space (less than 16 bits) for your high-bit-depth processing, you can use ConvertBits() as needed after your DGSource() call.

How should I feed that 16 bit stream to SMDegrain? LSB is not an option in this case, I think. The funny part would be also to output a dithered 10 bit video to feed x265 in Main10 profile or 8 bit to feed x264. Without thinking, at this moment, to HDR.

[real.finder]

From DGDecNV manual:

fulldepth: true/false (default: false)
When fulldepth=true and the encoded video is HEVC 10-bit or 12-bit, then DGSource() delivers 16-bit data to Avisynth with the unused lower bits zeroed. The reported pixel format is CS_YUV420P16. If either of the two conditions are not met, then DGSource() delivers 8-bit YV12 or I420 data, as determined by the i420 parameter. When fulldepth=false and the video is HEVC 10-bit or 12-bit, then the video is dithered down to 8-bit for delivery. If you need a reduced color space (less than 16 bits) for your high-bit-depth processing, you can use ConvertBits() as needed after your DGSource() call.

How should I feed that 16 bit stream to SMDegrain? LSB is not an option in this case, I think. The funny part would be also to output a dithered 10 bit video to feed x265 in Main10 profile or 8 bit to feed x264. Without thinking, at this moment, to HDR.

that for UHD BD or whatever original HBD source, in most cases your original source is 8 bit, and if it UHD then I don't think it's need any filtering or even re-encoding

anyway I don't know anything about DGDecNV, but ffms2 do it without any parameter and for avs+ it will output the HBD as it

and if you feed native HBD to SMDegrain it will work in most cases (if all filters that used are support HBD which I think in your cases all them are support HBD nowday)

and of course lsb is not option if your source is HBD, since mvtools has only lsb output

[tormento]

and of course lsb is not option if your source is HBD, since mvtools has only lsb output
I have read html again and what I have understood is:

lsb= true makes 32 bit denoising

lsb_in = true is used to get the source as native 16 bit (right?)

lsb_out = true outputs 16 bit clip as output

mode = 0…9 convert from internal 32bit to 8 bit (would be nice to have 10 or 12 too).

So, if I have a 16 bit video input (i.e. 10 bit with all upper 0), I should use lsb=true+lsb_in=true+lsb_out=true (unless you develop a mode for 10 and 12 bit), right?

[pinterf]

How on Earth is 32bit denoising achieved?

[real.finder]

I have read html again and what I have understood is:

lsb= true makes 32 bit denoising

lsb_in = true is used to get the source as native 16 bit (right?)

lsb_out = true outputs 16 bit clip as output

mode = 0Â…9 convert from internal 32bit to 8 bit (would be nice to have 10 or 12 too).

So, if I have a 16 bit video input (i.e. 10 bit with all upper 0), I should use lsb=true+lsb_in=true+lsb_out=true (unless you develop a mode for 10 and 12 bit), right?

these (lsb things) in SMDegrain are hack for the lsb (which it's hack by itself!), they use some dither tools (http://avisynth.nl/index.php/Dither_tools) method for do this, cuz there are no real lsb_in for mvtools (MDegrain*), mvtools has only lsb parameter that use 8bit input and output 16 bit as lsb, and lsb is not native in first place! it's hack use 8bit clip with double height

and this dither tools method (that used to support lsb_in by dogway) will not be real 16 bit, even if it better than doing 8bit

in short, for SMDegrain lsb and lsb_out are real 16 bit and it's ok for use them, but they still hack, lsb_in in SMDegrain will not be real 16 bit

and for dither back to 8 bit modes as pinterf said, it's not 32 bit, it's just 16 bit stacked

and these mode come from dither tools again, not in or from mvtools!

[pinterf]

Next version will come with that "bits" or whatever parameter that returns native 16bit instead of the stacked one from 8 bit source. The mv bitdepth independent inputs could be applied to other filters as well, I think.

[tormento]

The mv bitdepth independent inputs could be applied to other filters as well, I think.
So, if I understood well, at the moment a DGDecNV output from DGDecNV, that outputs a Ultra HD BD from 10 bits to 16bits with upper 0, is not natively useful when applying filters in a avisynth script with mvtools or dither, correct? We need dither (RGTools) update too, right?

[pinterf]

So, if I understood well, at the moment a DGDecNV output from DGDecNV, that outputs a Ultra HD BD from 10 bits to 16bits with upper 0, is not natively useful when applying filters in a avisynth script with mvtools or dither, correct? We need dither (RGTools) update too, right?
I meant that probably the same process - like with MDegrain was done - could be applied on MFlowXXX (using motion vectors from 8 bit clip (which is faster than the 10+bit path) and use them directly with 10+ bits clips)

[tormento]

I meant that probably the same process - like with MDegrain was done - could be applied on MFlowXXX (using motion vectors from 8 bit clip (which is faster than the 10+bit path) and use them directly with 10+ bits clips)
Understood. I know x265 Main10 is still a bit new and "experimental", especially with HDR. Ultra HD BDs are out and I would like to play a bit with them :)

[pinterf]

Understood. I know x265 Main10 is still a bit new and "experimental", especially with HDR. Ultra HD BDs are out and I would like to play a bit with them :)
10bit motion vectors (=10bit SAD) should be much faster than a generic 16bit one, checking this will be among of my next experiments.

[pinterf]

Next version will come with that "bits" or whatever parameter that returns native 16bit instead of the stacked one from 8 bit source. The mv bitdepth independent inputs could be applied to other filters as well, I think.
I'm ready with making native 16bit MDegrain output instead of the stacked one and now testing.

A new bool "out16" parameter was intruduced in MDegrains, which is basically the same as lsb=true but outputs native 16bit instead.

Quick tests show that the speed gain is not that much (comparing lsb=true and out16=true), 4-10% for a colorbars-addgrain-super-analyze-degrain session. Larger MDegrain level results in smaller gain.

[real.finder]

I'm ready with making native 16bit MDegrain output instead of the stacked one and now testing.

A new bool "out16" parameter was intruduced in MDegrains, which is basically the same as lsb=true but outputs native 16bit instead.

Quick tests show that the speed gain is not that much (comparing lsb=true and out16=true), 4-10% for a colorbars-addgrain-super-analyze-degrain session. Larger MDegrain level results in smaller gain.

4-10% are very good gain in this case

and if you can make it as int "bits" it will be better since user can use more option in this case to make good Speed vs Quality Balance :)

[pinterf]

4-10% are very good gain in this case

and if you can make it as int "bits" it will be better since user can use more option in this case to make good Speed vs Quality Balance :)
'Bits' cannot help with making it faster. Let me summarize.

MDegrain speed is primarily depends on the MAnalyze bitdepth: 8 bit super clip is fast, 10-16bits is not so fast (but I think it's still acceptable). As I mentioned, most of the time is spent on SAD calculation. I have a single code for the 10-16bits (2 bytes/pixel) case which can do even 16bit safely w/o overflow. If I have plenty of times, 10 and 12 bits could be optimized (partial sums of diffs would need only 16bits instead of 32 bits w/o overflow, which means lighter and faster 10bit SAD code) as the x264 or x265 project does.

O.K., we have the vectors with either 8bit or 10+bit method, the weigthed averaging in MDegrain is not a big bottleneck but there are still differences between source/target bitdepth combinations. Speedwise we have no difference between using 10 or 16 bit sources (and super).

8 bit source:
- basic: weighted avg calculation on 16bits rounded back to 8 bits, (overlaps result 16 bits), final result 8 bits
- lsb=true: weighted avg calc 16bits and kept (msb and lsb planes), (overlaps 32 bit), final result is 16 bits in the two 8 bit 'planes'
- out16=true: same as lsb=true but the intermediate calculation does not have to work with two 'planes' (msb and lsb), we have a single buffer which is good for speed.

10-16 bit source:
weighted avg calc 32bits rounded back to 16 bits, (overlaps 32 bit), result 16 bits

32 bit float source:
the averaging weights are still in 0-255 range, and the weight of the overlap windows are still in the 0-2048 range but the calculation is kept in floats.

weight: the averaging weight of motion matched backward and forward blocks from each clip (proportional with the block SADs)

[real.finder]

I see, but let's say that we want 32 bit output from 8 bit or 10 bit or whatever?

[pinterf]

I see, but let's say that we want 32 bit output from 8 bit or 10 bit or whatever?
All that I would do that I call ConvertBits when the result is ready. But I don't think it's the filter's task.

[real.finder]

All that I would do that I call ConvertBits when the result is ready. But I don't think it's the filter's task.

I mean as the lsb and out16 method

with bool out16 we can't do 16bit input > 32bit output, unless you add another bool as out32, or make it as int bits :)

[pinterf]

The 16 bit integer and 32 bit float output is substantially different inside and even needs preparation on the Super clip's level.
MDegrain is a smearing process, 16 bit integer precision is more than enough for it, I think.
When you want 32 bit output, you have to feed both the clip _and_ the super clip as 32bit float.

The idea of out16 and lsb is just not cutting back the bits of one intermediate integer processing step.

[pinterf]

New build, time to test and tweak your scripts again.
Download MvTools2 2.7.26 with Depans (https://github.com/pinterf/mvtools/releases/tag/2.7.26)

- 2.7.26 (20180314)
-New: MDegrain1-6 and N: new parameter bool "out16" = false. If set, 8 bit input results in native 16bit output (like lsb=true hack but this is native).
Faster than lsb=true by up to 12% (i7-7700)
-Faster: special 10 bit SAD functions instead of the generic 10-16bit one.
Depending on the block size, 4-17% gain for a typical MDegrain1-5 session

[real.finder]

thank you pinterf

time for new SMDegrain update

[tormento]

Depending on the block size, 4-17% gain for a typical MDegrain1-5 session
Did you mean MDegrain1-6?

[pinterf]

Yes. The 6th sense included :)

[burfadel]

Will this extend to 12 and 14 bits later?

[tormento]

Will this extend to 12 and 14 bits later
10 bit as it's a requirement of h265 Main10 profile.

Other 2 modes, AFAIK, are used on professional editing only.

[tormento]

New build, time to test and tweak your scripts again.
tr=4, lsb=true 10,41 fps
tr=4, 16 bit 11.96 fps +14,9%
tr=6, lsb=true 8,28 fps
tr=6, 16 bit 9,41 fps +13,6%

/me happy

P.S: When I am really desperate with dancing noise I use tr=9 (my psycological limit). Do you think there would be any speed difference with a software native version?

[pinterf]

New build with a small fix for an MDepan parameter. Thanks to veins1 for the report.

Download MvTools2 2.7.27 with Depans (https://github.com/pinterf/mvtools/releases/tag/2.7.27)

Change log (incl. the previous one)
- 2.7.27 (20180318)
- Fix: MDepan: use zerow parameter. The parameter had no effect probably since it had been introduced. (veins1)
- MDepan: report MT mode for Avisynth+. MT_MULTI_INSTANCE, except for logfile writing output mode when it reports MT_SERIALIZED.
(other filters already have proper registration, MDepan was missed)

- 2.7.26 (20180314)
-New: MDegrain1-6 and N: new parameter bool "out16" = false. If set, 8 bit input results in native 16bit output (like lsb=true hack but this is native).
Faster than lsb=true by up to 12% (i7-7700)
-Faster: special 10 bit SAD functions instead of the generic 10-16bit one.
Depending on the block size, 4-17% gain for a typical MDegrain1-6 session

[pinterf]

New build

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

- 2.7.28 (20180323)
- Fix: in MDegrain1-6/N allow Y8 input for out16 parameter

[tormento]

@pinterf

Please get a look here (https://forum.doom9.org/showthread.php?p=1837202#post1837202). It's a tiny job for you and it's often used with after MVTools :)

[burfadel]

I've come across a couple of things with MDegrainN. The first is the tr parameter. At the moment, instead of specifying tr=3 (for example), you have to leave it as a number, such that MDegrainN (super, multi_vec, 3). Wouldn't it be 'more ideal' to be able to specify tr=3 rather than just having a loose number there?

The second issue is Mrecalculate doesn't work with MAnalyse multi clip for MDegrainN.

In this most basic of running it, the following works:
super = MSuper()
multi_vec = MAnalyse (super, multi=true, delta=4)
MDegrainN (super, multi_vec, 4)

This doesn't:
super = MSuper ()
multi_vec = MAnalyse (super, multi=true, delta=4)
multi_vec = MRecalculate(multi_vec, tr=4)
MDegrainN (super, multi_vec, 4)

It errors with:
MRecalculate: Super clip does not contain needed color data
which isn't actually true (specying chroma and planes etc doesn't help).

I also have a couple of questions. What benefit does MDegrainN provide, for example in the script I quoted above, over using MDegrain4? Does it save memory, faster etc? Or is it purely for the use of large temporal radiuses like 10 for example?

Secondly, for MRecalculate, there's the option:
smooth

This is method for dividing coarse blocks into smaller ones.
0 Use motion of nearest block.
1 Bilinear interpolation of 4 neighbors.

Would there be any benefit from an adding an option 2 for bicubic interpolation, since it's 'cleaner'?

Thanks :)

[pinterf]

New build
Download MvTools2 2.7.29 with Depans (https://github.com/pinterf/mvtools/releases/tag/2.7.29)

Thanks for zorrozork for the report.

Fix: MFlowInter (and possibly other MFlow...) crash with specific combination
of analyze parameters (e.g. blkSize=16,overlapv=4,divide=1).
Bug existed since at least 2.5.11.22

[pinterf]

New build
Download MvTools2 2.7.30 with Depans (https://github.com/pinterf/mvtools/releases/tag/2.7.30)

Thanks for zorrozork for testing further.

- 2.7.30 (20180405)
Fix: crash in MFlowInter (and possibly other MFlow...). v2.7.29 revelead this additional bug (which was not even 100% reproducible),
this fix is basically the 2nd part of the solution.

- 2.7.29 (20180403)
Fix: MFlowInter (and possibly other MFlow...) crash with specific combination of analyze parameters (e.g. blkSize=16,overlapv=4,divide=1)
Bug existed since at least 2.5.11.22

[pinterf]

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

- 2.7.31 (20180409)
Fix: MFlow: SC detection after having the mv clip. Fixed in 2.5.11.22 but was missed during 2.6.0.5 merge.
Fix: MFlow: crash in 16bit 4:2:0, mode=1
Fix: MDegrain, out16=true: Green bottom lines when overlap blocks are not covering the full vertical area

[FranceBB]

Thank you for the new version. I might not comment at every release, but your work is really appreciated pinterf! :D

[Seedmanc]

Is truemotion really not supposed to be used with blocksizes above 16? Whenever I set it to true at 24 but especially 32 the video gets absolutely destroyed compared to truemotion false or blocksize 16 or below (using mflowfps for example).
I assume this is all due to the SAD thresholds/defaults being (still and why?) defined as absolute values instead of relative to block area and hence requiring the user to calculate them manually for the new blocksizes. But what should I use for 32? I tried multiplying lsad and lambda by 8 or 16, it didn't help.

[pinterf]

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

Thanks to Seedmanc for the report and providing useful test cases.

Change log
- 2.7.32 (20181018)
MAnalyze: Enhance mt mode report for Avisynth+: MT_SERIALIZED instead of MT_MULTI_INSTANCE when temporal=true or using output file.
MAnalyze: fix a possible internal overflow on larger blocksizes and lambda combinations. e.g. truemotion=true with blksize=32

[pinterf]

New build

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

Thanks to zorrozork and Seedmanc for the report.

**2.7.33 (20181021)**
- Fix: MFlowXX: random access violation caused by enlarged vectors pointing on out-of-frame positions

**2.7.32 (20181018)**
- New: MAnalyze: Enhance mt mode report for Avisynth+: MT_SERIALIZED instead of MT_MULTI_INSTANCE when temporal=true or using output file.
- Fix: MAnalyze: fix a possible internal overflow on larger blocksizes and lambda combinations. e.g. truemotion=true with blksize=32

[ChaosKing]

I think you forgot to upload the binary, there is no release download.

[FranceBB]

I think you forgot to upload the binary, there is no release download.

It's here https://github.com/pinterf/mvtools/releases/download/2.7.33/mvtools-2.7.33-with-depans.7z

He added it to the release page of Github ;)

[ChaosKing]

Did you clicked on that link? I get a 404 error

//Edit
link works now

[Sharc]

Thank you for the new version. I might not comment at every release, but your work is really appreciated pinterf! :D
+1
Thank you pinterf

[pinterf]

New build
Download MvTools2 2.7.34 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.34)
- 2.7.34 (20181108)
MFlowInter: Use less memory, eliminates ten full-frame internal buffers


This release is a side-effect of investigating memory issues when StainlessS' Duplicity2 script invoked plenty of MFlowInter instances and running the script in 32-bit Vdub2 resulted in crashes due to low memory. In a specific parameter scenario memory consumption reported by avsmeter went from 220/1624MiB to 213/1356MiB.

[StainlessS]

Sensational my man.
Ta very much :)

[FranceBB]

Ferenc, thank you for your efforts. ;)

[pinterf]

New build, a fix, thanks zorrozork for the report, his current project is really a stress test for possible parameter variations.

The other modifications are just experiments, pure leisure.

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

- 2.7.35 (20181113)
MFlowXXX: Slight speed gain by putting the out-of-frame vector check to resizer
Fix: MAnalyze: Fix a possible internal overflow on larger blocksizes with small overlap e.g. BlkSize=32, OverlapX=0, OverlapY=4
MSuper: Planar RGB support. Now MSuper supports Y and YUV and planar RGB 8-32 bits, and YUY2
note: different filters may support only a limited set of super clip formats.
MFlowFPS: Planar RGB support: generate vectors in YUV, use RGB input and super clip
MFlowFPS: less memory for 4:4:4 and greyscale
MFlowFPS: a bit faster 4:4:4, much faster greyscale
MFlowFPS: support different bit depth for clip and the vectors (use vectors from 8 bit analysis for a 16 bit clip)

[pinterf]

New build ahoy!
Download MvTools2 2.7.36 with depans (https://github.com/pinterf/mvtools/releases/tag/2.7.36)

Zork keeps feeding mvtools with a million parameter variations in his optimizer project.
These fixes heal a rather extreme case but nevertheless a smooth operation is always better than a funny divbyzero message :)

**2.7.36 (20181120)**
- Fix: Allow overlap operation when there are only two blocks in either horizontal or vertical direction (was: division by 0 crash)
- Fix: Fallback to overlap=0 mode when block count is only 1 in either h or v direction (was: undefined behaviour)
The cases above occured for small frame sizes, when frame size and overlap values resulted in less than 3 blocks in a direction.
- Misc: update html docs with overlap drawing and others.

[pinterf]

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

I have also noticed a small speed gain in some generic scripts (basic qtgmc fast)

**2.7.37 (20181128)**
- MCompensate: limit thSAD, thSAD2, thSCD1 to valid range 0-(8x8x255) (e.g. given thSAD = 100000 will go back to 16320)
- Fix: MCompensate: use int64 to avoid internal thSAD and thSAD2 overflow typically happen at bigger block sizes or large thSAD parameter value.
- MCompensate: SSE2 (8bit) and SSE4 (10-16 bit) overlap result calculation
- Changed: SAD 8x8, 8x4, 4x4, 4x8 to use SSE2 instead of MMX registers
- Fix: MDegrain if overlap<>0: missing rounder in rightmost 8 pixels for non-mod8 width 8 bit clips
- Fix: MSuper artifacts at 10-32 bits and nPel==4
- New: MCompensate 32 bit float and planar RGB support (by using motion vectors made from 8-16 bit YUV clip).
Input and super clip can be of a different format than the one used for motion vector creation. (Similar to MDegrain1-6)

[FranceBB]

Thank you very much indeed! :D

[StainlessS]

Small prob,


LoadVirtualDubPlugin ("Deshaker.vdf", "deshaker", preroll=0) # FAILS, "Error 0x7e"
LoadVirtualDubPlugin (".\Deshaker.vdf", "deshaker", preroll=0) # FAILS, "Error 0x7e"
#LoadVirtualDubPlugin ("D:\ShakeRattleAndRoll\Deshaker.vdf", "deshaker", preroll=0) # OK

[pinterf]

(offtopic here) Have you tried putting deshaker.vdf to plugins+ directory? Avisynth+ places vdubfilter.dll in plugins+ and not plugins.

[StainlessS]

(offtopic here)
Oops, yep, thought it was Avs+ thread, sorry.

I currently have it in both plugins and Plugins+. (x86 avs+)
I have to leave home this instant, already bout 1/2 hour late for appointment.