MCTemporalDenoise 'hanging'

[asarian]

I'm having great trouble with MCTemporalDenoise and "Ghost In The Shell". After max 1550 frames MCTemporalDenoise 'hangs'. It doesn't literally hang, but hovers at around 8% CPU and no longer outputs anything to x264. I've tried a dozen different decoders, removed all filters (except MCTemporalDenoise, of course); but, try as I might, after 1550 max frames, the process gets stuck.

I use the following script:

LoadPlugin("C:\Program Files (x86)\dgdecnv2026\DGDecodeNV.dll")

DGSource("f:\jobs\gits_test.dgi").ConvertToYV12()

Crop(32, 38, -32, -38)

MCTemporalDenoise(settings="medium")
GradFun2DBmod(thr=1.8,thrC=1.0,mode=0,str=2.4,strC=0.0,temp=50,adapt=64,mask=false,show=false)

LanczosResize(1920, 1038)

SupTitle("f:\jobs\gits_exp.sup", forcedOnly=false, swapCbCr=false, relocate=true, relocOffset="0,0,0,0")

I use the official AviSynth 2.58 release and the latest x264 release (run with --preset superfast for the test).

I prepared a small fragment (http://www.mediafire.com/?wmplmouxu2epoq3) (mediafire) which will cause the 'hang'. I would really appreciate it if someone knew why this occurs. Or at least can confirm it hangs on their machine too.

Much obliged.

[Didée]

Long story short: MCTemporalDenoise is a very demanding script with high complexity. Your source is 1080p. It's quite likely that RAM usage becomes too big, and there it goes down the drain.

Just for fun, you might try with "ReduceBy2()" right after loading the source. Still hanging? Probably not.

[asarian]

Thanks for your reply, Didée.

I generally use avs2yuv to pipe to a 64-bit x264 instance. This (apart from being able to use a 64-bit x264) also provides a memory separation, as it were, between everything AviSynth (+ filters) needs, and x264. Both processes, for full 1080p, never exceed 1.2G. I've done many movies like that, such as Highlander (very grainy, full 1080p) and Goodfellas. It seems more caught in a loop, really, than running out of memory (in fact, whenever I do run out of memory, I usually get a message saying avs2yuv has stopped responding). But it may well be a memory issue, after all.

As expected, adding a ReduceBy2() line causes the hanging to go away. But that's like having a completely different source. I can't really use that, of course. :) Sure wish there were a way to 'OSD' some of this stuff from MCTemporalDenoise to AviSynth.

[elguaxo]

I've done many movies like that, such as Highlander (very grainy, full 1080p) and Goodfellas.

Did you use the same MCTD settings when doing those?

From MCTD:

------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+---------------
SETTINGS | VERY LOW | LOW | MEDIUM | HIGH | VERY HIGH
------------+-----------------------------+-----------------------------+-----------------------------+-----------------------------+---------------
radius | 1 | 2 | 3 | 2 | 3

Among others "Medium" and "Very High" use MDegrain3 and that's exactly when I start having memory issues when dealing with 1080p in AviSynth.

Try for example MCTemporalDenoise(settings="medium",radius=2) or other settings that don't use a radius of 3.

[7ekno]

Ensure you are using the masktools-25 and not masktools-26 (also make sure only one version is in the directory) ...

Might also be worth trying the SSE2 versions of RemoveGrain and Repair (and also checking there aren't multiple versions in plugin directory) ...

7ek

[Didée]

Finding the exact culprit is difficult, so here's some more "poking in the blue":

- check not only the used memory, but also the virtual memory. (Have seen cases where private bytes were in range 1.2-1.5 GB, but virtual bytes jumped too high)

- add the "align=true" parameter to crop()

- try buffering the input file explicitely with RequestLinear() (from IVTC.dll) or with FrameCache (from WarpSharp.dll)

[asarian]

Thanks, Didée, and everyone else.

I managed to bypass the problem for now, wrapping a MT() call around the MCTemporalDenoise script, which no longer causes the hangup (guess it really was a memory issue, after all).

I will still try your collective suggestions, on the test sample, just to try and get a grasp of where things go wrong, for future reference.