Dogway's Filters Packs

[Zetti]

MeGUI seems to be the problem.

Becuase i moved your scripts out of the plugin folder and created my basic script with only the index file, and i have moved your scripts back.

Now i have tested my basic script and it's working with AVSMeter.

With your scripts in the plugin folder, i couldnt create the basic script with MeGUI.

So from now on, i need to import all the required plugins and scripts from another folder into my encoding script.

[Dogway]

Well thanks for testing, I checked and in "MeGUI/tools/avs" folder you find the avisynth dll files, you can try replacing those with v3.7.2 test3, just an idea.

[kedautinh12]

You can try L-SMASH in megui. And i use extools in megui normally

[Zetti]

Maybe i should check the Avisynth and AvisynthWrapper versions one more time.

And testing L-SMASH.

If that not getting it to work, a seperate folder could be the solotion.

[kedautinh12]

If you use latest avs+ ver, you need change new AvisynthWrapper to use latest avs+ ver
https://forum.doom9.org/showthread.php?t=181351

[Zetti]

I got it working without any errors after replacing the old versions of Avisynth and AvisynthWrapper with new ones in MeGUI.

Can you both have a great and wonderfull day.

[Boulder]

There seems to be some sort of a memory leak in QTGMC, at least when SRestore is involved. This script causes the memory usage to creep up until it hits the set memory limit, the Avisynth basically stalls. It does proceed, but at a very, very slow pace.
Replacing QTGMC with real.finder's STGMC fixes the issue, the memory usage stays below 1GB all the time.

SetMemoryMax(8192)
DGSource("source.dgi") # 1080i, 29.97 fps
QTGMC(preset="medium", noisepreset="fast", tr2=0, sigma=0.25)
Spline36Resize(1280,720)
SRestore()

[Dogway]

I'm pretty sure it's a memory leak in pixel addressing, it has been reported almost 2 months ago (https://forum.doom9.org/showthread.php?p=1960946#post1960946), and recalled 2 weeks ago (https://forum.doom9.org/showthread.php?p=1963618#post1963618) but pinterf has been turning a blind eye on it.

I will try to cobble up a version without pixel addressing so you can confirm. It's either that or a LUT bug.

[real.finder]

I'm pretty sure it's a memory leak in pixel addressing, it has been reported almost 2 months ago (https://forum.doom9.org/showthread.php?p=1960946#post1960946), and recalled 2 weeks ago (https://forum.doom9.org/showthread.php?p=1963618#post1963618) but pinterf has been turning a blind eye on it.

I will try to cobble up a version without pixel addressing so you can confirm. It's either that or a LUT bug.

maybe it's better to post it here https://github.com/AviSynth/AviSynthPlus/issues

[Dogway]

@Boulder: Test with this (https://pastebin.com/tmscgheP). I removed all pixel addressing calls, try to use the same threads than in STGMC, I don't know what's the default there.

[Boulder]

@Boulder: Test with this (https://pastebin.com/tmscgheP). I removed all pixel addressing calls, try to use the same threads than in STGMC, I don't know what's the default there.
There's a function missing:
error: Script error: There is no function named 'QTGMC_deflate'.
(C:/Program Files/AviSynth+/plugins64/qtgmc.avsi, line 1064)
(C:/Program Files/AviSynth+/plugins64/qtgmc.avsi, line 907)

[Boulder]

The issue might be partly related to SRestore as well. Running it in HBD also causes the leak with STGMC. It would be interesting to see if the tuned version of QTGMC handles 8-bits though, since the original version didn't. I'll doublecheck that one more time though.

SetMemoryMax(8192)
DGSource("source.dgi") # 1080i, 29.97 fps
STGMC(preset="medium", noisepreset="fast", tr2=0, sigma=0.25)
ConvertBits(16)
Spline36Resize(1280,720)
SRestore()

[Dogway]

Yes sorry, here are both functions from old QTGMC:


# Functions (from original TGMC) used instead of mt_xxflate with similar operation but a somewhat stronger result. Originally added for speed, they are
# no longer faster due to improvements in masktools. Difference (visual and speed) is small so may be reverted in a later version.
function QTGMC_inflate( clip c, int "Y", int "U", int "V" )
{
# >>>> YUY2 is planar here
mtY =default( Y, 3 )
mtU =default( U, 1 )
mtV =default( V, 1 )
rgY = (mtY == 3) ? 20 : -1
rgU = (mtU == 3) ? 20 : -1
rgV = (mtV == 3) ? 20 : -1
mt_logic( c, c.RemoveGrain( rgY, rgU, rgV ), "max", Y=mtY,U=mtU,V=mtV )
}

function QTGMC_deflate( clip c, int "Y", int "U", int "V" )
{
# >>>> YUY2 is planar here
mtY =default( Y, 3 )
mtU =default( U, 1 )
mtV =default( V, 1 )
rgY = (mtY == 3) ? 20 : -1
rgU = (mtU == 3) ? 20 : -1
rgV = (mtV == 3) ? 20 : -1
mt_logic( c, c.RemoveGrain( rgY, rgU, rgV ), "min", Y=mtY,U=mtU,V=mtV )
}

If STGMC also shows a memory leak in HBD (16-bit I understand) it could be a LUT problem. LUT calculations, at least for 16-bit are enabled for ex_lut()/mt_lut() only.

One more thing, it has been a long time I used srestore() but as far as I recall it was very picky with frame access. I used to use it only with MP_Pipeline() for these reasons or at another pass. You can also try to put RequestLinear() before the call.

[Dogway]

On another note, I coded a few new filters for ExTools, usually this involves several iterations that don't make the cut to the final version but there still might be some value on them.
This time it happened with Harris corner detection, I created one version that differs from the canonical one from the papers but IMO performs better.
So here it is the "by the book" Harris corner detection with helper function Non-Maximum Suppression.

# Harris corner detection
#
# Alternative version which works well for small images and graphics
function ex_corner_canon(clip a, float "sigma", float "th", bool "show") {

rgb = isRGB(a)
isy = isy(a)
bi = BitsPerComponent(a)

rd = Default(sigma, 1.4)
th = Default(th, 0.7) # From 0.1 to 0.9
sh = Default(show, false)
th = th/10000.

a = ConvertBits(a,32)
a

x1 = ex_lut("x[0,-1] x[0,1] - dup *").ex_blur(rd,mode="gaussian")
y1 = ex_lut("x[-1,0] x[1,0] - dup *").ex_blur(rd,mode="gaussian")
xy = ex_lutxy(x1,y1,"x y * ").ex_blur(rd,mode="gaussian")
# xy = ex_lut("x[0,-1] x[0,1] - abs x[-1,0] x[1,0] - abs max").ex_blur(rd,mode="gaussian")

ex_lutxyz(x1,y1,xy,"x y * z - x y + dup * 0.05 * -",UV=2) # R = Det(M) - k*Trace(M)^2
ex_NMS(thin=1.0) # In the paper this goes after thresholding, but this resulted better on my tests
ex_lut(Format("x {th} > range_max 0 ?"),UV=2)
# Alternative without suppression
# ex_lutxyz(x1,y1,xy,Format("x y * z - x y + dup * 0.04 * - {th} > range_max 0 ?"),UV=2)

# Corner augment
ex_expand(3,mode="disk").ex_deflate()

# Show
sh ? ex_blend(a,last, "linearadd", 0.4, 1.0) : last
ConvertBits(bi) }


# Non-Maximum Suppression (NMS) - Edge Thinning Algorithm
#
# ex_NMS(thin=0.3) # 15.5 (164 without scaling)
# awarpsharp2(chroma=2, depth=12, blur=4, thresh=128) # 167
# aWarpSharp(depth=8,blurlevel=2,thresh=0.5) # 182
#
function ex_NMS(clip a, float "thin", bool "show") {

ss = Default(thin, 0.5) # Super sampling factor
sh = Default(show, false)
ss = min(4.0,1./ss)

RatioResize(a,ss,"%",kernel="blackman",src_left=0.25,src_top=0)

ex_lut("x[0,-1] T@ x[0,1] B@ -
x[-1,0] L@ x[1,0] R@ -
atan2 0.1591549431 * dup 0 > swap dup 1 + ? 180 * A@

157.5 > x[0,0] X@ T > X B > & X L ?
A 112.5 > X x[1,-1] UR@ > X x[-1,1] DL@ > & X DL ?
A 67.5 > X L > X R > & X T ?
X x[-1,-1] UL@ > X x[1,1] > & X UL ? ? ? ? ",UV=2)

RatioResize(1./ss,"%",kernel="bicubic",b=0,c=1)

ex_limitdif(a, last, thr=2, elast=5, UV=2) }

[Boulder]

I think I found the culprit after many rounds of debugging - it's propCopy and that's why your QTGMC leaks memory since STGMC doesn't use the props feature at all.

This won't stall:
DGSource("source.dgi")
STGMC(preset="medium", noisepreset="fast", tr2=0, sigma=0.25)
propSet("_FieldBased", 0)
Spline36Resize(1280,720)
SRestore()

While this will:
DGSource("source.dgi")
org=last
STGMC(preset="medium", noisepreset="fast", tr2=0, sigma=0.25)
propCopy(last, org)
propSet("_FieldBased", 0)
Spline36Resize(1280,720)
SRestore()

I think I need to report this in GitHub along with the other property related issue I found earlier.

[Dogway]

Oh, that one was also reported (https://forum.doom9.org/showthread.php?p=1956036#post1956036) back in October, still no word from pinterf.

So you are saying that my QTGMC mod without propCopy is fine? Or do you want to keep debugging it?

[guest]

Can someone explain why this is happening...

I have a PC with an old AMD R9 290 GPU (which DOES NOT support CUDA), and when I use BM3D CUDA, of course it fails, BUT, I have also installed a basic GTX 650 (which DOES support CUDA).

And now, if I use BM3DCUDA, both are encoding, using OpenCL.

The R9 290 is a LOT faster as it has 40 compute units, whereas the poor little GTX 650 only has 2.

[poisondeathray]

Can someone explain why this is happening...

I have a PC with an old AMD R9 290 GPU (which DOES NOT support CUDA), and when I use BM3D CUDA, of course it fails, BUT, I have also installed a basic GTX 650 (which DOES support CUDA).

And now, if I use BM3DCUDA, both are encoding, using OpenCL.

The R9 290 is a LOT faster as it has 40 compute units, whereas the poor little GTX 650 only has 2.

GTX 650 is too old

https://github.com/WolframRhodium/VapourSynth-BM3DCUDA

Requirements

CUDA-enabled GPU(s) of compute capability 5.0 or higher (Maxwell+).

[guest]

GTX 650 is too old

https://github.com/WolframRhodium/VapourSynth-BM3DCUDA

I don't care about requirements, it just WORKS !!!!!!

[poisondeathray]

I don't care about requirements, it just WORKS !!!!!!

ahh I misunderstood;

Maybe CPU fallback ? What were the CPU's between the 2 systems?

How are you measuring OpenCL usage ? What encoder are you using ? (is it using OpenCL as well) ?

[kedautinh12]

GTX 650 is too old

https://github.com/WolframRhodium/VapourSynth-BM3DCUDA

Test 8 now support compute capability 3.5 and higher

[guest]

ahh I misunderstood;

Maybe CPU fallback ? What were the CPU's between the 2 systems?

How are you measuring OpenCL usage ? What encoder are you using ? (is it using OpenCL as well) ?

Well, my post was asking how can this be working ??

It's an i7 3930K. which only supports AVX, so BM3DCPU doesn't work, and when I only had the AMD R9 290 installed, it could not use BM3DCUDA, but now that I've installed the "old" GTX 650, the encoding app seems to be able to use both GPU's when using BM3DCUDA.

The encoding app is RipBot264, which is sadly way out of date, but still works quite well.

I have a Ryzen 3950X with an AMD RX 480 (which doesn't support CUDA), so I put an old GTX 760, and the same applies, it just works :)

I also have a couple of Xeon E5 2690's, with old AMD HD6850's & GTX 650's, and it works the same way :)

[guest]

Test 8 now support compute capability 3.5 and higher

Hi ked, I'm not using Vapoursynth, tho...

[Boulder]

Oh, that one was also reported (https://forum.doom9.org/showthread.php?p=1956036#post1956036) back in October, still no word from pinterf.

So you are saying that my QTGMC mod without propCopy is fine? Or do you want to keep debugging it?

Your debug version worked fine once I commented out line 964 which had the propCopy call.

[WolframRhodium]

BM3DCUDA may run on GTX650, but it is not guaranteed by CUDA. It should not be able to run on R9 290, the usage data may be erroneous.

[kedautinh12]

Hi ked, I'm not using Vapoursynth, tho...

I say about avs ver

[guest]

BM3DCUDA may run on GTX650, but it is not guaranteed by CUDA. It should not be able to run on R9 290, the usage data may be erroneous.

Yes, that is why I asked the question in the first place, I was shocked when it appeared that RipBot264 WAS using the OpenCL (with BM3DCUDA).

With the Distributed Encoding feature of RipBot264 you have the option to use a specific GPU to do the encoding.

So when using BM3DCUDA, and have the R9 290 on one server/port, and the GTX 650 on another server/port?, they both appear to be encoding, and at different speeds, due the difference in the Compute Units of both cards.

However without the GTX 650, BM3DCUDA cannot be used.

[guest]

I say about avs ver

It's just that that link sent me to the Vapoursynth version info. AFAIK.

[kedautinh12]

But name ver i said related avs :D
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/issues/7#issuecomment-886173346

[guest]

But name ver i said related avs :D
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/issues/7#issuecomment-886173346

Sorry....but this link was different, but made sense. :)

[pinterf]

Oh, that one was also reported (https://forum.doom9.org/showthread.php?p=1956036#post1956036) back in October, still no word from pinterf.

So you are saying that my QTGMC mod without propCopy is fine? Or do you want to keep debugging it?
I think that was a completely different problem (speed). To address your problem propCopy was changed then in order to not copy all the frame content but to use "SubFrame" internally (you as a script writer do not need to know what env->SubFrame is), which is able to keep frame content without actually copying any byte in its planes. The same "subframe" technique is used to make quick SeparateFields, aligned crop, ExtractX, etc.

I suppose this memory leak appeared after this change, because of this subframe-hack which I have to investigate why it doesn't release its memory or clip reference of I don't know what.

[pinterf]

I'm pretty sure it's a memory leak in pixel addressing, it has been reported almost 2 months ago (https://forum.doom9.org/showthread.php?p=1960946#post1960946), and recalled 2 weeks ago (https://forum.doom9.org/showthread.php?p=1963618#post1963618) but pinterf has been turning a blind eye on it.

I will try to cobble up a version without pixel addressing so you can confirm. It's either that or a LUT bug.
Well, probably I have blind eyes but if you'd follow things on git you would realize that I'm not just sitting at home, eating pizza and watching clouds on the sky, plus I've got an official job. In last November I went to a cinema and watched Dune, that was the last time I had time watching _any_ films.

[pinterf]

I think I found the culprit after many rounds of debugging - it's propCopy and that's why your QTGMC leaks memory since STGMC doesn't use the props feature at all.

This won't stall:
DGSource("source.dgi")
STGMC(preset="medium", noisepreset="fast", tr2=0, sigma=0.25)
propSet("_FieldBased", 0)
Spline36Resize(1280,720)
SRestore()

While this will:
DGSource("source.dgi")
org=last
STGMC(preset="medium", noisepreset="fast", tr2=0, sigma=0.25)
propCopy(last, org)
propSet("_FieldBased", 0)
Spline36Resize(1280,720)
SRestore()

I think I need to report this in GitHub along with the other property related issue I found earlier.
Has someone accidentally minimize the script? I omitted SRestore and resize, replaced STGMC (this must be a new thing I'm not aware of) with QTGMC and it is still consuming more and more memory, I wonder which part of it must be kept in order to still reproduce the problem?

[kedautinh12]

Well, probably I have blind eyes but if you'd follow things on git you would realize that I'm not just sitting at home, eating pizza and watching clouds on the sky, plus I've got an official job. In last November I went to a cinema and watched Dune, that was the last time I had time watching _any_ films.

Dune is very good film for me :D

[pinterf]

Not only propCopy(last, org) fails but other two-clip filters as well, replacing propCopy with Stackvertical(last,org) or Merge(last,org) yields the same effect.
I have to remove functions from QTGMC one-by-one until the phenomenon stops occuring, since probably some other function call combination inside QTGMC triggers this leak.

btw:
propCopy now gets/sets everything.
Would it be good have a new parameter to be able to pass an array of property names?
Then only selected properties would only be extracted and copied?

[Dogway]

Your debug version worked fine once I commented out line 964 which had the propCopy call.

Could you test vanilla without propCopy? So we can discard pixel addressing.


I think that was a completely different problem (speed). To address your problem propCopy was changed then in order to not copy all the frame content but to use "SubFrame" internally (you as a script writer do not need to know what env->SubFrame is), which is able to keep frame content without actually copying any byte in its planes. The same "subframe" technique is used to make quick SeparateFields, aligned crop, ExtractX, etc.

Speed issues typically uncover under the hood issues. But I mean you as a mere programmer don't need to know what hysteresis is, nor even maths at all.

Well, probably I have blind eyes but if you'd follow things on git you would realize that I'm not just sitting at home, eating pizza and watching clouds on the sky, plus I've got an official job. In last November I went to a cinema and watched Dune, that was the last time I had time watching _any_ films.

Now we are two (no time even for Dune :(). I do follow things on git, I was just replying to this post (https://forum.doom9.org/showthread.php?p=1962901#post1962901). You made such a fuss about not reporting but I actually do and most of it pass ignored, so I'm not going to annoy anyone that I know is so busy with other tasks as I see on git.

propCopy now gets/sets everything.
Would it be good have a new parameter to be able to pass an array of property names?
Then only selected properties would only be extracted and copied?

Thanks, finally (https://forum.doom9.org/showthread.php?p=1956543#post1956543) it gets implemented. Typically it's only "_ColorRange" what I need to restore, but having also ALL as an option is useful.

QTGMC is a good Expr() testbench because it takes it to its limits. I hope Boulder can answer if vanilla without propCopy() is fine.

[Boulder]

Could you test vanilla without propCopy? So we can discard pixel addressing.

Yes, it works. The issue appears to be a particularly nasty one and reproducable with a very simple script.

https://github.com/AviSynth/AviSynthPlus/issues/270

I'd like to add my 2c to the GitHub reporting issue as an IT guy. I definitely want to bring up things but even if I do, I don't expect them to be handled. It's always up to the maintainer to decide that, I see reporting just a perfect way to keep things in mind. The issues are very easily lost in the long threads. In your case I've made a difference since you frequent the forum a lot these days.

[Dogway]

I'd like to add my 2c to the GitHub reporting issue as an IT guy. I definitely want to bring up things but even if I do, I don't expect them to be handled. It's always up to the maintainer to decide that, I see reporting just a perfect way to keep things in mind. The issues are very easily lost in the long threads. In your case I've made a difference since you frequent the forum a lot these days.

Thanks for the report. It's a matter of time, if you report to GitHub you are supposed to dedicate enough time to debug, time I don't have, and probably pinterf either.
These days I would rather finish the last touches of my scripts because I'm burned out and switch to other things.

[Boulder]

Thanks for the report. It's a matter of time, if you report to GitHub you are supposed to dedicate enough time to debug, time I don't have, and probably pinterf either.
These days I would rather finish the last touches of my scripts because I'm burned out and switch to other things.

I always try to give enough information to be useful, that's also because of my background. At work, I get quite a lot of requests for assistance which lack a lot of information so I have to either guess or ask too many questions to do something about things.

What comes to being burnt out - your scripts already work very well. It's very much possible to take a break and come back to the ideas in the summer or whenever. Of course, if there's some dependency type of bugs found, it's a bit different but I guess the most used functions are in good shape.

[Dogway]

Yes, normally my reports whenever possible are very low level examples with Expr(), but beyond that I don't have time to debug with other conditions, compare old versions, etc.

I have an internal todo list and it's pretty much over. I had Harris corner there for a few months now, and now for ExTools the only thing left is some bugs in ex_makediff() when show=1, and update propCopy() calls to latest (unreleased) AVS+ version (also to other scripts). I will probably promote it to v8.0. It's not perfect but it's where I reach for now.

The only other thing left is MasksPack, I probably can optimize ex_limitdif() further. And finish Soothe() refactor. That's all, besides the Zopti thingy and SceneStats() which is a big but fun thing to do. There are more but for the future I guess.

[Dogway]

Updated ExTools to v7.6. Now all scripts are promoted to AVS+ v3.7.2 due to expected propCopy() refactor, at which time I will rebase all my scripts.
Here is the new filter ex_corner(), based on Harris corner detection but with some own modifications.
https://i.imgur.com/GjHHdaFh.png

[pinterf]

That propCopy issue is a nasty one, it's not because of properties because this pure script similarly exhibits the 'leak'.
ColorBars(pixel_type="YV12",staticframes=false)
org=last
Bob()
Merge(last, org)

Art of skeletonizing of QTGMC :)

The issue is inherited from times shortly after Neanderthals discovered Avisynth+ (I was able to go back to r1825 from 1996). After two days I think it is internal cache related, an otherwise smart cache size auto-optimization was fooled by the scenario of combining an original and a double rate clip. Resolving the problem is in progress, I've got already a non-memory-exhausting version on my test bench but I have a feeling that this workaround in this form would be suboptimal for other cases.

See the issue here (https://github.com/AviSynth/AviSynthPlus/issues/270)

[Dogway]

Only exhibits the issue for double-rate merging? I trimmed the output of Bob() to match length and still showed memory leak.

Maybe this might be related (don't know) to the optimization (https://forum.doom9.org/showthread.php?p=1959004#post1959004) that was present in Merge() (talking out of my a**). Thanks for looking into it.

[pinterf]

What happens when you put SelectOdd(org) instead of org? (I'm not near my PC) or better: Interleave(org,org)

[Dogway]

What happens when you put SelectOdd(org) instead of org? (I'm not near my PC) or better: Interleave(org,org)

Both options are fine.

By the way, do you know if there's such thing as IsRuntime(), so I can disable LUT in this environment, I can do a try catch though but it's not pretty.

function isRunTime(clip a, bool rgb) {
try {
iRT = rgb ? a.AverageR() : a.AverageLuma()
iRT = true
} catch ( error_msg ) {
iRT = false
}
return iRT }

[pinterf]

Both options are fine.

Technically propCopy(last, Interleave(org,org)) is what you need to use. This will pull the proper frame properties. because Nth original frame becomes (2N)th after QTGMC.

Or else - because of frame doubling - the filter before 'org' (in my example ColorBars, or ffms) is receiving the following frame request pattern (actually copied from my log file):

0, 0, 0, 1, 1, 2, 1, 3, 2, 4, 2, 5, 3, 6, 3, 7, 4, 8, 4, ...
44, 22, 45, 23, 56, 23...


Jumping to and fro is not healthy for any source filter (nor for Avisynth+ internal cache algorithm :) )

Using Interleave for this kind of propCopy will not only make the source of copying correctly placed but will speed up the whole thing - at least it won't make it slow down because of out-of-order frame requests. I hope I didn't write much nonsense. I recommend you trying it out.

[Dogway]

But in this case we are pulling frameprops from frame#0. If using offset though frame order is important, same if run in runtime env.

- Allow propGetXXX property getter functions called as normal functions, outside runtime
By default frame property values are read from frame#0 which index can be overridden by the offset parameter

About Bob()+Merge(), I see that the frame request is N and 2N at the same time so the source loader suffers jumping up and down.

Anyway I tested with "output.propCopy(bobbed)" in QTGMC and it worked fine. But I will wait until you add selective frameprop copy if you still plan to add it.


EDIT: Boulder, updated QTGMC() give it a try now, so far looks fine here. I had to port sh_bob() to inherit some frame properties.

[Boulder]

The new version works fine, no memory leaks whatsoever :)

[salvo00786]

Hi...
Dogway, please can you help me?
I'm trying to use your latest version of QTGMC with Ripbot, but when I try to preview the script, appear the message: cannot render the file. If i use the old QTGMC the preview start. I have updated all the dll of the core plugins to the version requested by the avsi file. This is the part of the script relative to QTCMG

#Deinterlace
Loadplugin("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\SysInfo0129\SysInfo64.dll")
Loadplugin("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\vinverse\vinverse.dll")
Loadplugin("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\vsTCanny\vsTCanny.dll")
Loadplugin("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\RgTools\RgTools.dll")
Loadplugin("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\nnedi3\nnedi3.dll")
Loadplugin("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\masktools\masktools2.dll")
Loadplugin("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\mvtools\mvtools2.dll")
Import("A:\PORTABLE\RipBot264v1.26.0\Tools\AviSynth plugins\Scripts\QTGMC.avsi")
video=AssumeTFF(video).QTGMC(Preset="Medium",FPSDivisor=1)

[Dogway]

Hi...
Dogway, please can you help me?
I'm trying to use your latest version of QTGMC with Ripbot, but when I try to preview the script, appear the message: cannot render the file. If i use the old QTGMC the preview start.

What AviSynth+ version do you use? I recommend using latest v3.7.2 test3 (https://forum.doom9.org/showthread.php?t=181351). And redownload QTGMC (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/QTGMC.avsi) just in case, as I had a typo yesterday.