New Plugins and Utilities

[anton_foy]

It no more need MVs for motion compensation - it can run as simple enough blend engine for already motion compensated frames (MVs dx, dy equal to dx=0,dy=0). With internal protection against bad blends where RIFE fails with motion compensation. Today at testing I found internal tr=1 RIFE denoise based on simple (non-bad blends protected) Average() plugin works looks like OK. At 1080p clip and GTX1060 card even 2 AVS+ threads already saturate 'compute1' performance counter to 100% and fps reach 4 limit. Single thread run at about 3 fps. CPU load is only 5%. More AVS+ threads only increase GPU memory load and at about 5 threads it crashes with vk_errors (like out of memory).

But attempt to output motion compensated frames to external blending engine fails (looks like some bug corrupts AVS environment) - reported to Asd-g. Or may be it is bug in old (3.7.3 AVS+ version) - we wll see later.

Script like

src_den=last
tr1=RIFE(denoise_tr=1, denoise_blending_mode=1)
tr2=RIFE(denoise_tr=2, denoise_blending_mode=1)
Average(src_den, 0.2, tr1, 0.4, tr2, 0.4)

corrupts AVS+ environment (clip 'src_den' got much more frames as before RIFE() calls) and Average() plugin fails. At least with my AVS+ version of 3.7.3. Same is with attempt to use 'last' variable in the Average().

Latest version of avisynth+: https://gitlab.com/uvz/AviSynthPlus-Builds

Edit: I don't know how fluxsmoothT does but it is suppose to be motion protected (temporal median?)?

[kedautinh12]

Latest ver here:
https://forum.doom9.org/showthread.php?p=1983179#post1983179

[DTL]

Updated RIFE become better - https://github.com/Asd-g/AviSynthPlus-RIFE/issues/2#issuecomment-1435699935

It is tested with external blending engine of plugin MedianBlurTemporal and it looks produce significantly sharper result in compare with simple Average().

Now testing 1080i clip processing with simulation of tr=2 (if it correctly processed in MedianBlurTemporal with such arguments passing)

LoadPlugin("RIFE.dll")
LoadPlugin("VMAF.dll")
LoadPlugin("MedianBlur2.dll")

FFmpegSource2("src.mxf")

ConvertToYV12(interlaced=true)

SeparateFields()

src=last

ConvertToRGB()
ConvertToPlanarRGB()
ConvertBits(32)

tr1=RIFE(denoise=true, denoise_tr=1, denoise_blending_mode=1, skip=true, sc=true, sc_threshold=0.05)
tr2=RIFE(denoise=true, denoise_tr=2, denoise_blending_mode=1, skip=true, sc=true, sc_threshold=0.05)

tr1=ConvertToRGB24(tr1).ConvertToYV12()
tr2=ConvertToRGB24(tr2).ConvertToYV12()

Interleave(tr1, src, tr2)
MedianBlurTemporal(radiusy=0, radiusu=0, radiusv=0, temporalradius=1)
SelectEvery(3, 1)

Weave()

Prefetch(2)


At 2 threads of AVS the performance at GTX1060 6 GB is about 2 fps. GPU-Z shows GPU chip power about 100..120Watt. CPU load is very low about 5%.

Testing shows it is important to adjust sc_threshold by content to avoid bad interscenes interpolated frames at scenechanges. The default 0.12 may be too high for low-contrast scenechange. Too low value may cause unstable RIFE processing inside scene and flickering or no denoise at all. It looks skip=true uses VMAF for scenechange detection and it looks work better.

[kedautinh12]

RIFE_denoise3 now
https://github.com/Asd-g/AviSynthPlus-RIFE/issues/2#issuecomment-1435768729

[anton_foy]

Updated RIFE become better - https://github.com/Asd-g/AviSynthPlus-RIFE/issues/2#issuecomment-1435699935

It is tested with external blending engine of plugin MedianBlurTemporal and it looks produce significantly sharper result in compare with simple Average().

Now testing 1080i clip processing with simulation of tr=2 (if it correctly processed in MedianBlurTemporal with such arguments passing)

LoadPlugin("RIFE.dll")
LoadPlugin("VMAF.dll")
LoadPlugin("MedianBlur2.dll")

FFmpegSource2("src.mxf")

ConvertToYV12(interlaced=true)

SeparateFields()

src=last

ConvertToRGB()
ConvertToPlanarRGB()
ConvertBits(32)

tr1=RIFE(denoise=true, denoise_tr=1, denoise_blending_mode=1, skip=true, sc=true, sc_threshold=0.05)
tr2=RIFE(denoise=true, denoise_tr=2, denoise_blending_mode=1, skip=true, sc=true, sc_threshold=0.05)

tr1=ConvertToRGB24(tr1).ConvertToYV12()
tr2=ConvertToRGB24(tr2).ConvertToYV12()

Interleave(tr1, src, tr2)
MedianBlurTemporal(radiusy=0, radiusu=0, radiusv=0, temporalradius=1)
SelectEvery(3, 1)

Weave()

Prefetch(2)


At 2 threads of AVS the performance at GTX1060 6 GB is about 2 fps. GPU-Z shows GPU chip power about 100..120Watt. CPU load is very low about 5%.

Testing shows it is important to adjust sc_threshold by content to avoid bad interscenes interpolated frames at scenechanges. The default 0.12 may be too high for low-contrast scenechange. Too low value may cause unstable RIFE processing inside scene and flickering or no denoise at all. It looks skip=true uses VMAF for scenechange detection and it looks work better.

Can use Clense() instead of MedianBlurTemporal, its faster.
http://avisynth.nl/index.php/MedianBlur2

Same as Clense() but much slower:
MedianBlurTemporal(radiusy=0, radiusu=0, radiusv=0, temporalradius=1)

[DTL]

Yes - instead of Interleave/blurtemporal/selectevery it may work simple

Clense(src, tr1, tr2)

Also it looks the skip may be default false and not used for scenechenge detection as I understand. I can not test new build until about middle of next week. You may try any blending engine that work good for you.

Also Clense http://avisynth.nl/index.php/RgTools/Clense looks like 8bit only.

[Reel.Deel]

Also Clense http://avisynth.nl/index.php/RgTools/Clense looks like 8bit only.

No, it supports HBD also. That page has not been updated but the table in the main page has: http://avisynth.nl/index.php/RgTools#Filters

[Tempter57]

RIFE_denoise3 now
https://github.com/Asd-g/AviSynthPlus-RIFE/issues/2#issuecomment-1435768729

Unfortunately on given version RIFE_denoise3 has faced a problem
RIFE: skip cannot be used for denoise_tr greater than 1

Used skip=false

[DTL]

Can use Clense() instead of MedianBlurTemporal, its faster.
http://avisynth.nl/index.php/MedianBlur2

Yes - with interleaved input it work equally to MedianBlurTemporal and a bit faster. But not work with 3-clips provided as Clense(src, tr1, tr2). Or may be I not understand how it work with 'previous' and 'next' optional clips.

Also as alternative blending engine possibly vsTTempSmooth may be tested https://github.com/Asd-g/AviSynth-vsTTempSmooth . It have more settings about temporal weigthing and thresholding. May it can better save from residual bad blends passed via Clense and MedianBlurTemporal (without settings to make better protection from bad blends).

[anton_foy]

Yes - with interleaved input it work equally to MedianBlurTemporal and a bit faster. But not work with 3-clips provided as Clense(src, tr1, tr2). Or may be I not understand how it work with 'previous' and 'next' optional clips.

Also as alternative blending engine possibly vsTTempSmooth may be tested https://github.com/Asd-g/AviSynth-vsTTempSmooth . It have more settings about temporal weigthing and thresholding. May it can better save from residual bad blends passed via Clense and MedianBlurTemporal (without settings to make better protection from bad blends).

Yes vsTTempsmooth is very good but sadly very slow. If you need more than 3 clips for clense I think Dogway has scripted an extended version?

[DTL]

Yes vsTTempsmooth is very good but sadly very slow.

It is simply because it is still C-only and process each sample in a long enough loop. If put to SIMD it should work several times faster.

[kedautinh12]

Unfortunately on given version RIFE_denoise3 has faced a problem
RIFE: skip cannot be used for denoise_tr greater than 1

Used skip=false

You can try with stable ver here:
https://github.com/Asd-g/AviSynthPlus-RIFE/releases

[kedautinh12]

It is simply because it is still C-only and process each sample in a long enough loop. If put to SIMD it should work several times faster.

Try new ver, asd-g refactor code, maybe make it faster?
https://github.com/Asd-g/AviSynth-vsTTempSmooth/releases

[DTL]

Version of vsTTempSmooth 1.2.1 with SSE2/AVX2/AVX512 added https://github.com/Asd-g/AviSynth-vsTTempSmooth/releases/tag/1.2.1

About 3.2 times faster at FullHD frame YV12, maxr=7 with AVX2 at i5-9600K.

Still have VirtualDub crash if trying to feed separated fields after RIFE(). The 'progressive' frames looks works good.

[anton_foy]

Version of vsTTempSmooth 1.2.1 with SSE2/AVX2/AVX512 added https://github.com/Asd-g/AviSynth-vsTTempSmooth/releases/tag/1.2.1

About 3.2 times faster at FullHD frame YV12, maxr=7 with AVX2 at i5-9600K.



Thanks DTL great news! Did you do the update or Asd-g? Edit: ok I see Asd-g optimized it.

[DTL]

Asd-g is great programmer and made SIMD update with new-generation of SIMD library of vector functions (not intrinsics low-level based but with more high-level syntax). Currently I see some place of possibly better performance if current design issue will be somehow changed - gathering array of pre-calculated weights pointed by each sample diff value is strangely very slow and eats about 50% of total fps. So may be if that issue with gathering internal service data (not input planes samples) will be workarounded somehow (may be even runtime weight calculation instead of pre-calculated array with poor SIMD performance) we can get about 2x more processing speed.

Also in new uploaded 1.2.1 release the crash with separated to planes interlaced was finally fixed. At least at my current quick tests. Better more users testing required before closing issue about one possible crash reason.

As I see vsTTempSmooth rarely used in large users scripts and marked as 'stronger' in MCTD.avsi https://github.com/Asd-g/AviSynthPlus-Scripts/blob/3a0da2968b9a67a702c9678162e09a85895190a2/MCTD_.avsi#L52 if used instead of MDegrain.

[Dogway]

As I see vsTTempSmooth rarely used in large users scripts and marked as 'stronger' in MCTD.avsi https://github.com/Asd-g/AviSynthPlus-Scripts/blob/3a0da2968b9a67a702c9678162e09a85895190a2/MCTD_.avsi#L52 if used instead of MDegrain.

If it had an option for binomial weights I think it could be used more, I don't know in what cases IDW is more useful? Or TemporalSoften with binomial, whatever fits better.

[DTL]

For simple denoising work after (perfect) motion compensation the simple enough blending engine may be used. The protection from bad blends may be started from simple threshold-based for low enough noise levels (but still very visibly degrades MPEG compression performance as shown in https://forum.doom9.org/showthread.php?p=1983505#post1983505 ).

The temporal-distance-based weighting is only sort of additional decreasing of possible bad part in the total output blend result for 'far from current' frames motion compensated expecting its quality of motion compensation is significantly worse in compare with 'near' frames. It may increase quality (sharpness) on moving parts of image but decrease denoising in static parts of footage with typically equal quality of motion compensation over total tr-distance.

As I understand current vsTTempSmooth may use additional difference-based weighting with some smooth weighting curve (like weight for other frame sample=f(difference between current and other frame sample) and that pre-computed table for it) - to not have too hard discontinuity at the threshold-based decision of either blend samples values or not (i.e. weight either 1 or 0) based on the difference.

I still not sure if binomial weighting can make better signal to noise level in case of working with natural gaussian-distributed photon shot noise. Are there any research about it available ? Or may be it is more effective against bad blends in case of not perfect motion compensation ?

Currently for performance at todays CPUs with SIMD the best algorithm must be SIMD-friendly with no inter-sample-dependent runtime computing and without random pre-computed lookup table usage (gathering) for each 'SIMD-thread' processing each sample separately. Currently usage of pre-computed weights table with per-sample data gathering in non-SIMD fallback like https://github.com/Asd-g/AviSynth-vsTTempSmooth/blob/f71a46709225add4670452c697815cbfa8196b44/src/vsTTempSmooth_AVX2.cpp#L55 degrade performance at about 50%. Also usage of new data-gathering instructions of AVX512 (partially started from AVX2) can not helps greatly because cache still slow on fetching data from different lines and even levels. The switching from 'scalar single threaded' computing to SIMD 'internal multi-threading' also require changing of algorithm to get all possible benefits from SIMD.

So may be some new 'simple-fast weighting' mode for vsTTempSmooth possible to use is with external motion compensation engine with much more simplified and SIMD-friendly weighting for significantly better performance.

[DTL]

Release 1.2.3 of vsTTempSmooth https://github.com/Asd-g/AviSynth-vsTTempSmooth/releases/tag/1.2.3 looks like final version with SIMD optimizations added. Run about 8..10x times faster in compare with C-ref (opt=0) at AVX512 chip depending on processing mode (use difference- and frame-distance weighting (slower) or only frame-distance weighting (faster)). AVX2 is about 20..30% slower.

Scalar gathering loop in C finally was changed to SIMD gather hardware instruction (more SIMD-way of execution) https://github.com/Asd-g/AviSynth-vsTTempSmooth/blob/77400e19d990ff7251c99b24af8e7d4bda644692/src/vsTTempSmooth_AVX512.cpp#L88 available at AVX2 and AVX512 architectures and last significant slowing down part of processing was removed. Now vsTTempSmooth Asd-g version 1.2.3 can be used (added to AVS documentation like FilterSDK) as example of simple enough processing re-design to use SIMD architectures. It have C-reference and SIMD implementations of the same processing at 3 different SIMD architectures SSE2/AVX2/AVX512.

[mastrboy]

Release 1.2.3 of vsTTempSmooth https://github.com/Asd-g/AviSynth-vsTTempSmooth/releases/tag/1.2.3 looks like final version with SIMD optimizations added. Run about 8..10x times faster in compare with C-ref (opt=0) at AVX512 chip depending on processing mode (use difference- and frame-distance weighting (slower) or only frame-distance weighting (faster)). AVX2 is about 20..30% slower.

Scalar gathering loop in C finally was changed to SIMD gather hardware instruction (more SIMD-way of execution) https://github.com/Asd-g/AviSynth-vsTTempSmooth/blob/77400e19d990ff7251c99b24af8e7d4bda644692/src/vsTTempSmooth_AVX512.cpp#L88 available at AVX2 and AVX512 architectures and last significant slowing down part of processing was removed. Now vsTTempSmooth Asd-g version 1.2.3 can be used (added to AVS documentation like FilterSDK) as example of simple enough processing re-design to use SIMD architectures. It have C-reference and SIMD implementations of the same processing at 3 different SIMD architectures SSE2/AVX2/AVX512.

Thanks, I use that filter often, always nice to see performance improvements.

[Reel.Deel]

BlockDetect: determines blockiness of frames.
https://github.com/Asd-g/AviSynthPlus-BlockDetect

[DTL]

DecodeYV12toRGB (only interleaved RGB32 currently, planar RGBP8 possible) - https://github.com/DTL2020/ConvertYV12toRGB

Some faster and simple quality (point-resize UV) colour-space convert filter, mostly for UHD frame size and draft/preview quality (for monitoring ?). AVX2 minimum CPU required.
Should work close to ConvertToRGB32(chromaresample=point) in quality.

[Reel.Deel]

BlurDetect: Determines blurriness of frames by adding the relevant frame property.
https://github.com/Asd-g/AviSynthPlus-BlurDetect

[StainlessS]

CacheTest(), https://forum.doom9.org/showthread.php?t=184920

Debug Filter.
Writes Messages to DebugView window. Requires DebugView.
Writes repeat frame requests and Out Of Sync frame requests [requested not previous requested frame + 1] to Debugview.

Some results for manually jumping about a bit

00001691 0.22455139 [10788] CacheTest_0001: 0] *** Initialized to frame 0 {RepeatCnt=0, oSyncCnt=0}
00001692 1.09279370 [10788] CacheTest_0001: 0] *** REPEAT REQUEST (ReSeek to 0, Player starts to play ???), {RepeatCnt=0, oSyncCnt=0}
00001693 4.92930794 [10788] CacheTest_0001: 89] *** OUT OF SYNC REQUEST, Previous=122 {RepeatCnt=0, oSyncCnt=1}
00001694 4.93385696 [10788] CacheTest_0001: 2582] *** OUT OF SYNC REQUEST, Previous=89 {RepeatCnt=0, oSyncCnt=2}
00001695 10.90573597 [10788] CacheTest_0001: 2722] *** OUT OF SYNC REQUEST, Previous=2755 {RepeatCnt=0, oSyncCnt=3}
00001696 13.87600136 [10788] CacheTest_0001: 14400] *** OUT OF SYNC REQUEST, Previous=2722 {RepeatCnt=0, oSyncCnt=4}
00001697 16.37423706 [10788] CacheTest_0001: 0] *** Rewind to frame 0, Previous=14400, Counts RESET {RepeatCnt=0, oSyncCnt=0}
00001698 46.82066727 [10788] CacheTest_0001: 674] *** OUT OF SYNC REQUEST, Previous=707 {RepeatCnt=0, oSyncCnt=1}
00001699 47.55070114 [10788] CacheTest_0001: 708] *** OUT OF SYNC REQUEST, Previous=705 {RepeatCnt=0, oSyncCnt=2}


[ DebugView v4.90, @ Micro$oft:- https://learn.microsoft.com/en-us/sysinternals/downloads/debugview ]

[kedautinh12]

MapNLQ
https://github.com/Asd-g/AviSynthPlus-MapNLQ/releases

[Reel.Deel]

DualSynth-madVR - VapourSynth/AviSynth madVR wrapper
https://github.com/Irrational-Encoding-Wizardry/DualSynth-madVR

PolyphaseResize - AviSynth filter for scaling pixel-perfect sources (no binary, just source)
https://github.com/djrideout/PolyphaseResize

[kedautinh12]

Can anyone have binary of PolyphaseResize? Thanks

[DTL]

This is builds of PolyphaseResize with VS2019 - https://drive.google.com/file/d/1aMCTmDUWUQpb3SEZu9Wg0pL5dPWAqVrM/view?usp=sharing . Looks like a not finished version - it uses not clear conversion from float to int and at main processing looks like unbiased conversion from float to byte (compiler warnings). So may have more quantization noise left. It works without crashing (x64 tried) but looks close to PointResize ?

[Reel.Deel]

Thanks DTL. I'm not sure what it is supposed to look like but in the source it says it uses the coefficients from here: https://github.com/MiSTer-devel/Filters_MiSTer/blob/master/Filters/Interpolation%20(Sharp).txt

[kedautinh12]

This is builds of PolyphaseResize with VS2019 - https://drive.google.com/file/d/1aMCTmDUWUQpb3SEZu9Wg0pL5dPWAqVrM/view?usp=sharing . Looks like a not finished version - it uses not clear conversion from float to int and at main processing looks like unbiased conversion from float to byte (compiler warnings). So may have more quantization noise left. It works without crashing (x64 tried) but looks close to PointResize ?

It's the same x64 plugin.dll in the x86 folder

[Reel.Deel]

intellibravs - Intelligent Brightness plugin for AviSynth+
https://github.com/thedeemon/intellibravs

[tormento]

AVX2 minimum CPU required
Since what release number?

[tormento]

MapNLQ
What is it for?

I find scarce if no information about polinomial luma mapping.

[kedautinh12]

What is it for?

I find scarce if no information about polinomial luma mapping.

https://github.com/Asd-g/AviSynthPlus-MapNLQ

[tormento]

https://github.com/Asd-g/AviSynthPlus-MapNLQ
I read it before asking. No hint about its purpose.

[PoeBear]

I read it before asking. No hint about its purpose.

"About: Dolby Vision mapping for AviSynth."

It allows you to recreate the output of Dolby Vision UHDs with FEL tracks

[DTL]

Since what release number?

Since first development build. It was designed as simple and fast solution as working tech demo of moving pictures data processing at the era of AVX2 and later SIMD capable CPU chips in 202x years. The first end-users AVX2 chips is something about beginning of 201x years (Haswell in 2013 ?).

[tormento]

Since first development build. It was designed as simple and fast solution as working tech demo of moving pictures data processing at the era of AVX2 and later SIMD capable CPU chips in 202x years. The first end-users AVX2 chips is something about beginning of 201x years (Haswell in 2013 ?).


Wait me!

I am waiting for Arrow Lake or Zen 5! [emoji28]

[DTL]

First release of M_QTGMC() . https://github.com/DTL2020/QTGMC/releases/tag/m_0.1 (M is sort of Monster-QTGMC)

It opens Super and Ultra Slow processing. Release includes required new .dlls - release for test of mvtools2 2.8.0-a.00 and new created plugin MostDiffVal (used in M_QTGMC). Also some version of QTGMC2() based on Dogway version v3.384s .

With current settings (internal) it attempt to create sharpest possible - so most of noise also keeping in.

M_QTGMC is aggregator of 4 calls to QTGMC2 with blocksizes of 8x8 and 16x16 and PP on (for preset="slow") and off. Also each calls of QTGMC2() uses new AreaMode (with not very high AM params - only +4 additional points of search) of MVs internal refining in MAnalyse and new predictor modes for TrueMotion and for median predictor.

Total performance is expected about 0.1 of classic QTGMC(preset='slow') or maybe a bit higher. (Update: at Core2Duo E7500: 11 vs 0.17 fps = 64x times slower.)

Test on BetacamSP (into DV25) capture: https://imgsli.com/MjYxMTMx https://imgsli.com/MjYxMTQx

Most of details saving expected at fast moving subjects. Also may add something good to old noised BetacamSP sources.

Also supplementary plugin MostDiffVal https://github.com/DTL2020/MostDiffVal/releases/tag/0.1 . It may be somehow created using Expr() but I do not know how. It used in function GetSharpest(clip1, clip2) and can be used to create sharpest version of a clip from 2 different processing ways each making sharpest only some parts of a frame and blurs others.

Update 2: With i5-9600K CPU it is not so slow - only about 6x times slower in compare with QTGMC(preset="slow") with x264 running with preset=slow for h.264 transcoding. 7.5 fps with M_QTGMC and 45 fps with QTGMC.

[DonCanjas]

First release of M_QTGMC() . https://github.com/DTL2020/QTGMC/releases/tag/m_0.1 (M is sort of Monster-QTGMC)

It opens Super and Ultra Slow processing. Release includes required new .dlls - release for test of mvtools2 2.8.0-a.00 and new created plugin MostDiffVal (used in M_QTGMC). Also some version of QTGMC2() based on Dogway version v3.384s .

With current settings (internal) it attempt to create sharpest possible - so most of noise also keeping in.

M_QTGMC is aggregator of 4 calls to QTGMC2 with blocksizes of 8x8 and 16x16 and PP on (for preset="slow") and off. Also each calls of QTGMC2() uses new AreaMode (with not very high AM params - only +4 additional points of search) of MVs internal refining in MAnalyse and new predictor modes for TrueMotion and for median predictor.

Total performance is expected about 0.1 of classic QTGMC(preset='slow') or maybe a bit higher. (Update: at Core2Duo E7500: 11 vs 0.17 fps = 64x times slower.)

Test on BetacamSP (into DV25) capture: https://imgsli.com/MjYxMTMx https://imgsli.com/MjYxMTQx

Most of details saving expected at fast moving subjects. Also may add something good to old noised BetacamSP sources.

Also supplementary plugin MostDiffVal https://github.com/DTL2020/MostDiffVal/releases/tag/0.1 . It may be somehow created using Expr() but I do not know how. It used in function GetSharpest(clip1, clip2) and can be used to create sharpest version of a clip from 2 different processing ways each making sharpest only some parts of a frame and blurs others.

Have you tried using globals to try speeding up the script?
https://raw.githack.com/Dogway/Avisynth-Scripts/master/MIX%20mods/QTGMC%20Docs%20(v3.33).html#ExternalLinkage

Support for progressive input would be much appreciated, by me at least

Note: Why the loading and imports in M_QTGMC? I find it odd since avs+ auto loads plugins/scripts

[DTL]

If you mean MVs reusage between different calls to QTGMC via globals - it is not possible because the total idea of M_QTGMC is gathering details from different QTGMC calls with different MVs search params (different block size and different pre-processing). The details keeping or blurring at different areas of QTGMC output depends on the generated by MAnalyse MVs field and it is different for different analysis params (block size and pre-processing and others).

M_QTGMC is a sort of additional layer of 'statistical wrapper' around QTGMC processing to gather max variance from a set of observations of 2D random values. It is 'anti-denoise' processing. So with details it also gathers max residual noise over all areas of a frame. It can be also used with QTGMC 'classic' (and mvtools-2.7.x) - simply make a copy and remove all params of mvtools-2.8.x (named mvt_*). It will be much faster and also gather some more details.

"Support for progressive input would be much appreciated, by me at least"

I am not good at script writing. So it means we simply need to pass all not-used params from the M_QTGMC wrapper to underlying QTGMC calls ? I will try to do it in the next version.

"Why the loading and imports in M_QTGMC? I find it odd since avs+ auto loads plugins/scripts"

I do not use auto-loads in AVS+ and different mvtools versions can not be mixed with a single AVS+ process. So I think the only way to use different versions of mvtools is to load all required .dlls from a given path from the script (current working dir or any other). I hope but I not sure if loading some .dll from script directly can prevent AVS from loading 'auto-load' same named .dll from some 'auto-load' path too ? Also users of Computers become more and more lazy and the number of AVS required .dlls become more and more so users typically complain that it is too hard to find all required .dlls (and in the required versions) to run complex scripts (like QTGMC). So I include all required .dlls in the release archive and script loads it from the current working dir. So users can simply unpack the archive to some dir and it is ready to use as a 'portable' version on any host with only AVS+ core .dll installed. And with the addition of source plugin by user's choice.

I think this reply may be moved to either some thread for QTGMC or may be a new thread if there is some discussion for this update.

Addition: The only idea about globals: M_QTGMC with mvtools 2.8.x can export MVs for example for next denoise stage gathered from all internal QTGMC calls and averaged via MAverage() filter added in 2.8.0 build. Because computing of good MVs is very expensive - the already computed MVs may be reused in some next processing. It is possible in next versions but only will be compatible with mvtools 2.8 and later. Also typical QTGMC only produces MVs for tr=6 max in current versions. Though we can ask pinterf to add MAverage and MTransform new filters to 2.7.x builds too - they are simple and separate from all others.

[FranceBB]

I'm posting it here 'cause I don't know where else to say this.
Besides, I'm also not really sure whether anyone needs it, but here's the thing: asd-g ported BWDIF to Avisynth here https://github.com/Asd-g/AviSynth-BWDIF/releases and he did an amazing job, however he didn't include XP compatible builds.
In case anyone needs them, I've included them here: https://github.com/FranceBB/BWDIF/releases/
All credits are on asd-g for all the hard work, I've just got his release, constrained the whole thing to SSE2, included /Zc:threadSafeInit and compiled with v141_xp targeting Windows XP x86 x64.
I've only really tested it on XP x86 'cause I don't have an x64 version lying around, but it should work on x64 too nonetheless.
I also added a tiny link in the wiki at the end of the page here: http://avisynth.nl/index.php/BWDIF pointing to the XP compatible builds too.
Please note that I've also included the standard Windows x64 x86 builds compiled with v143, however if you're on Windows 10/11, unless you wanna be constrained to SSE2 only, you should really use the official asd-g ones compiled by him with the Intel Compiler which include AVX2 and AVX512 as well.

[tormento]

Someone should update DGDecNV wiki page. It's way outdated, missing all the new internal filters.

[Reel.Deel]

AviSynthDeinterlaceSwitch: plugin for switching between two clips depending on if the scenes in the source clip are interlaced or not.
https://github.com/MvonSchantz/AviSynthDeinterlaceSwitch

AviSynthFilmGrain: filter for adding realistic film grain to videos using the algorithm described in "Realistic Film Grain Rendering".
https://github.com/MvonSchantz/AviSynthFilmGrain

[Reel.Deel]

JoshUpscale - Upscales and refines video (480x270 -> 1920x1080) using AI model. Made for upscaling GTA VCS streams.
https://github.com/itmo153277/JoshUpscale

[v0lt]

MPC Script Source 0.2.1.165 (https://github.com/v0lt/ScriptSourceFilter/releases/tag/0.2.1)
The filter allows to open AviSynth+ and VapourSynth script files in DirectShow video players.

[tormento]

https://github.com/Asd-g/bore

This approach to border deringing uses linear least squares (https://www.gnu.org/software/gsl/doc/html/lls.html) to find a proper adjustment.

[rgr]

https://github.com/radpopl/MergeClips/

# -------------------------------------------------------------------------------------------------------
# Concatenating clips of different resolutions by enlarging smaller ones and optionally adding black bars
# -------------------------------------------------------------------------------------------------------
#
# MergeClipsV (clip Clip1, clip Clip2, string resize="Lanczos")
# MergeClipsV (clip_array Clips, string resize="Lanczos")
# - Returns a clip that is a concatenation of proportionally enlarged clips whose height is equal to the height of the HIGHEST clip. Black bars are added to the sides of individual clips if necessary. The "resize" parameter defines the upscaling method.
#
# MergeClipsH (clip Clip1, clip Clip2, string resize="Lanczos")
# MergeClipsH (clip_array Clips, string resize="Lanczos")
# - Returns a clip that is a concatenation of proportionally enlarged clips whose width is equal to the width of the WIDEST clip. Black bars at the bottom and top are added to individual clips if necessary. The "resize" parameter defines the upscaling method.
#
# Notice:
# - the format of all clips must be the same except for width and height
# - I suggest converting to YUV444 or RGB before calling the function, and converting the final clip back to the target format (for better resize quality)
#
# (v1.0)
#

[hello_hello]

rgr,

I hadn't played with arrays much before, so after seeing your functions I used them as a bit of a learning exercise and created a new variation in the process. This one requires my CropResize function. The width, height and borders arguments are optional.

Usage:
MergeClips([A,B,C,D], W=960, H=540, Borders=true)

MergeClips.avsi (https://files.videohelp.com/u/210984/MergeClips.avsi)

[rgr]

rgr,

I hadn't played with arrays much before, so after seeing your functions I used them as a bit of a learning exercise and created a new variation in the process. This one requires my CropResize function. The width, height and borders arguments are optional.

Usage:
MergeClips([A,B,C,D], W=960, H=540, Borders=true)

MergeClips.avsi (https://files.videohelp.com/u/210984/MergeClips.avsi)

I understand, but the idea of ​​MergeClips is to enlarge to the size of the largest clip, not to a given resolution.

In the latter case, it is better to use CropResize.

The idea came when I had to combine several clips from a miniDV camera, each 720px wide and DAR 4:3, but different heights (quasipanorama with black bars). The 720x576 fragments get black bars on the sides, and the 720x436 fragments are enlarged to 952x576 (which width you don't have to calculate).