QTGMC Deinterlacing Script (v3.32)

[Gavino]

Do it like this:
...
Distributor()
Whether or not to call Distributor() depends on how the client (encoder, player, etc) calls Avisynth. If it uses the VfW interface or if is MT-aware, you will end up calling it twice, creating twice as many threads.

[kypec]

Whether or not to call Distributor() depends on how the client (encoder, player, etc) calls Avisynth. If it uses the VfW interface or if is MT-aware, you will end up calling it twice, creating twice as many threads.
Sorry, didn't quite understand what you're trying to say with this:confused:
I'm using this Avisynth script either through avs2avi.exe (as intermediate file) or directly fed into x264.exe (perhaps piped over avs2yuv.exe with 64-bit x264).
Should I or should I not include Distributor() statement then?

[Gavino]

I don't know - it's not something I've had to deal with in practice as I have only ageing single-core machines and don't actually use MT. :(

What I do know is that Distributor() (described here (http://avisynth.org/mediawiki/MT_modes_explained)) is the function that creates the threads and controls their interaction, and is automatically added to the filter chain when Avisynth is used through VfW.
This will not happen with an application that invokes Avisynth directly, but the application may be clever enough to detect a multi-threaded Avisynth and call Distributor() itself.

If Distributor() is not called at all, you won't get any multithreading.
OTOH, if it is called twice, you will get twice as many threads, with unnecessary additional overhead.

So it's important to know what your Avisynth client already does in this respect.
Unfortunately, I don't know what the answer is for either avs2yuv, avs2avi, or x264. :(

[aegisofrime]

I think the simple solution will be to just try 2 scripts, one calling Distributor and one without, and see which one is faster for you. I tested this myself a long time ago and using Distributor was much faster than without. I use MeGUI to encode to x264 btw.

[AnXioZ]

It sounds like you might have your field order wrong. Try adding either AssumeTFF() or AssumeBFF() before calling QTGMC.
Yep, the field order was wrong... You are awesome! Thank you!

[-Vit-]

@Vit: Any release date for the new version? :)
It's finished, just one very minor bug to fix. Tomorrow.

[-Vit-]

Just posted the latest version 3.0 (http://forum.doom9.org/showthread.php?p=1423459). There are many new features and the script has been significantly overhauled. Please advise of any issues I've introduced.

Highlights
- A new algorithmic step called "source-match" which gives higher fidelity output and is more accurate to the source
- Simplified and improved lossless output (related to above)
- Improved progressive modes (InputType=2,3), which now use a motion mask to help recover more detail (progressive also supports source-match)
- Motion-compensated noise bypass. Effectively providing an alternate deinterlacing path for detail not amenable to interpolation
- Major documentation improvements - more user-friendly categorized information with many examples of use
- See version history in script for more...

The original algorithm is unchanged apart from a couple of minor bug fixes so existing scripts should work the same. No speed increases in this version, the changes all focus on quality.

For even more detail than this post look at the documentation in the script itself. I've split the algorithm into categories (e.g. Sharpness, Progressive Input). For each category I've provided a summary, full description, settings/defaults list and usage examples. Hopefully that will allow people to get the most out of the script without guesswork.

Impatient? tl:dr? This is the essence of the new features, higher quality than the previous version:
QTGMC( Preset="Slow", MatchPreset="Very Fast", SourceMatch=3, Lossless=2, NoiseBypass=2, NoiseDeint="Generate" )
________

Source-Match
The binomial (née Gaussian) smooth used at the core of the (Q)TGMC algorithm does a great job of removing bob-shimmer, but leaves the image blurred. The original algorithm resharpens to recover, but that process is far from ideal: sometimes it oversharpens and it's unable to recover lost detail in any case.

Source-match is an alternative to full resharpening that captures more source detail, noticeably improving perceived vertical "resolution". It also reduces the potential for oversharpening / haloing. There are three stages of source-match, each refining the last, which take the smoothed image and restore it to match the source without introducing shimmer. Once matched, further sharpening then becomes somewhat of an optional extra. Clearly these modes involve extra processing (see tech detail below). I'm going to cover this feature in depth, but please be aware that this is a precise and subtle effect for those requiring exacting detail only.

***Examples***
Here are some samples to show the difference. This is a 720p sample (from the "in_to_tree" video at Xiph.org (http://media.xiph.org/video/derf/)) thinned to 720i and then re-bobbed. This is a crop with a 3x zoom. All lossless x264 in MKV. The QTGMC settings used are later in this post.

First a comparison of placebo settings with source-match and placebo without. Look for the additional "resolution" with source match - this is genuine extra detail, not sharpness.
Placebo_Comparison.mkv (http://www.mediafire.com/?5szm5xfsn92o8kp) (300k)

Next a comparison of the 720p source and two source-match examples. This is a comparison of true 720p and bobbed 720i, I find this impressive given such a detailed source.
Note that source-match improves detail, but does not fix interpolation errors (as shown by the lines on the roof, which NNEDI3 joined up incorrectly)
Source_Comparison.mkv (http://www.mediafire.com/?6kcahljmqizr9mj) (500k)

A comparison at default settings with and without source-match ("Slower" preset).
Standard_Comparison.mkv (http://www.mediafire.com/?8h2l9eul8dl9yjm) (300k)

Full sample movies with and without source match. Although there is a demonstrable increase in detail in every frame, the differences may only be apparent on a large display or upscale (I did say it was a precise effect!). The source-match is frame-by-frame very close to the raw source. I should probably calculate some metrics, maybe later...
Source_Match.mkv (http://hotfile.com/dl/99271509/771258f/Source_Match.mkv.html) (720p 237Mb)
No_Source_Match.mkv (http://hotfile.com/dl/99279643/aabd97a/No_Source_Match.mkv.html) (720p 222Mb)

Using Source-Match
The templates below increase in both quality and slowness.

# Choose preset as required (very fastest presets are not suitable though)
# Start with Sharpness=0.2 and adjust as necessary. Use TR2=1 for a clean source, use TR2=2
# or TR2=3 (slower) if more denoising is required, or alternatively use Noise Bypass
QTGMC( Preset=XXXX, SourceMatch=1, Sharpness=XXX, TR2=X ) # Basic mode, fastest
QTGMC( Preset=XXXX, SourceMatch=1, Lossless=2, Sharpness=XXX, TR2=X ) # Good quality, efficient, minor residual combing
QTGMC( Preset=XXXX, SourceMatch=3, Sharpness=XXX, TR2=X ) # Good quality, slower, no combing
QTGMC( Preset=XXXX, SourceMatch=3, Lossless=2, Sharpness=XXX, TR2=X ) # Best quality, slowest, very minor residual combing

Caveats
Because of its very nature, source-matching will faithfully recover artefacts in the source. Consider this if you have a poor source. Similarly, it's sensitive to source noise. Increase TR2 to 2 or 3 for extra denoising or use noise bypass. Source match modes 2 and 3 occasionally introduce minor aliasing, relatively rare though. They occasionally repair aliasing too.

Source-matching requires additional interpolations / temporal smooths depending on mode. Expect slower processing. However, you can use somewhat faster presets and still get results better than no source-matching. See the algorithm section below or the source-match category in the script to find out about source-match presets for speed tweaking.

At this point I've barely tested source-match with the very high speed modes (so much to test on this version), but I don't recommend it since the improvements will be insignificant against those lower quality modes.
________

Lossless
Most of the lossless settings have been removed, superseded by source-match. Only one setting remains: Lossless=1 = true lossless. Lossless=2 = "fake" lossless. Both lossless modes will add a little extra detail to the output. But both lossless modes can also create combing where they don't match the other field lines. So they both work much better with SourceMatch=3 as this will ensure the best possible match (the combing will be very minor compared to previous versions). Lossless mode 1 can still create a shimmery incongruity between alternate lines though. Lossless mode 2 occurs prior to sharpening and the final smooth, which allows some measure of tweaking. That means lossless mode 2 isn't exactly lossless - this mode is better seen as an optional extra for source-match (can be applied alongside any source-match mode).

Examples above.
________

Noise Bypass
I consider noise bypass to be an alternate method to deinterlace components of the image which cannot be interpolated effectively - noise, fine texture, very subtle detail. Things that the binomial smooths might also blur away. The idea is to split the input into clean-image and noise/fine-detail and send each part down it's respective route to be reassembled at the end. There are two changes for this:

Firstly the addition of DetailRestore, which works together with NoiseRestore. It controls how much noise is restored prior to the final temporal smooth. This seems counter-intuitive, restoring noise prior to denoising, but the final denoise can be fairly light and will allow through detail extracted as noise. This detail may not have survived the two stronger temporal smooths that it bypassed.

Secondly, the NoiseDeint="Generate" setting is now motion-compensated. The noise, extracted from an interlaced source, is "deinterlaced" to create a full height frame of noise to add back at the end. The "Generate" setting uses AddGrain to generate new noise for the missing fields and now does something like an "MGrain" with the neighboring frame - kind of the opposite of MDeGrain - it doesn't smooth the noise but uses the motion compensated neighbor frame as a guide to help build the noise in the current frame. This creates a sequence of noise that is fairly bob-shimmer free (but otherwise "noisy").

Here are a couple of examples:

QTGMC( Preset="Slower", NoiseBypass=2, NoiseDeint="Generate" ) # Note that "Generate" mode is rather slower than the alternatives
QTGMC( Preset="Slower", NoiseBypass=2, NoiseRemove=1.0, DetailRestore=0.4, NoiseRestore=0.2, Sigma=1.8, NoiseDeint="Generate" )
For the lighter NoiseBypass=1, start with the sum of Noise+DetailRestore = 1.0 and adjust to taste. For the stronger NoiseBypass=2, start with the sum = 0.4.

You can visualize the noise by setting ShowNoise=X, where X is a value around about 4.0 to 8.0. This will display the extracted noise as output (display contrast determined by X). Can use this to see the "Generate" mode deinterlacing the noise in your video. Or more usefully it helps to select a good Sigma value (which determines how much noise is extracted).
________

Progressive Input
InputType=2 or 3 are designed for repairing progressive material with severe deinterlacing artefacts (or other horizontal artefacts). They effectively drop half the "fields" and reweave, so the less aggressive InputType=1 should be preferred when it works effectively. But for those sources where InputType=1 is not effective enough, there is now a setting ProgSADMask that helps modes 2 and 3 recover more detail in stable areas.

All InputTypes support source-match as described above. This particularly helps InputTypes 2 & 3 recover detail, it's less useful for InputType=1. Using ProgSADMask and SourceMatch can produce surprisingly good results for some sources.
________

Scripts used in Samples

# All QTGMC scripts began with:
RawSource("in_to_tree_420_720p.y4m")
SeparateFields().SelectEvery(4,0,3).Weave()

# Placebo_Comparison
a = QTGMC( Preset="Placebo", MatchPreset="Medium", SourceMatch=3, Lossless=2, MatchEnhance=0.7, Sharpness=0.1, tr2=1, \
NoiseBypass=2, NoiseRemove=1.0, DetailRestore=0.5, NoiseRestore=0.1, Sigma=3, NoiseDeint="Generate" )
# vs
b = QTGMC_2_51( Preset="Placebo", tr2=1, Sharpness=0.8, NoiseBypass=2, NoiseRemove=1.0, NoiseRestore=0.3, Sigma=3, NoiseDeint="Generate" )

# Source_Comparison
a = RawSource("in_to_tree_420_720p.y4m")
# vs
b = QTGMC( Preset="Placebo", MatchPreset="Medium", SourceMatch=3, Lossless=2, MatchEnhance=0.7, Sharpness=0.1, tr2=1, \
NoiseBypass=2, NoiseRemove=1.0, DetailRestore=0.5, NoiseRestore=0.1, Sigma=3, NoiseDeint="Generate" ) # Retain grain
# vs
c = QTGMC( Preset="Placebo", MatchPreset="Medium", SourceMatch=3, Lossless=2, MatchEnhance=0.7, Sharpness=0.15, tr2=3, \
NoiseBypass=2, NoiseRemove=1.0, DetailRestore=0.3, NoiseRestore=0.0, Sigma=3, NoiseDeint="Generate" ) # Denoise

# Standard Comparison
a = QTGMC( Preset="Slower", SourceMatch=3, Lossless=2 )
# vs
b = QTGMC_2_51( Preset="Slower", Sharpness=0.8 )


Continued...

[-Vit-]

Continued from post above, go there for basics...

Source Match Algorithm
Here's the algorithmic detail on this new addition to the core algorithm. There are three stages, basic, refined and twice-refined:

Basic Source-Match
Intuitively, a deinterlacer should just inject new fields into the source leaving the original pixels untouched. Unfortunately, the binomial smooth used to remove bob-shimmer also changes the original fields - the output no longer matches the source. So find the difference between the source and the equivalent fields in the output. Then a trick: using this difference, calculate a revised source that, when binomially smoothed, would result in an output that does match our original source. We then interpolate and binomially smooth this new source. Having gone through a binomial smooth the result will be shimmer free and, by definition, it will match the original source.

The formula used for this correction is:
P0' = P0 + (P0 - P1)/(k + S(1-k)), where:
P0 is original source
P1 is the output after the first attempt at interpolation/smoothing
P0' is the revised source for second attempt at interpolation/smoothing
k is the weighting given to the current frame in the binomial smooth
S is a factor indicating "temporal similarity" of the error correction required from frame to frame,
i.e. S = average over all pixels of (neighbor frame error / current frame error)
Decreasing S will make the result sharper, sensible range is about -0.25 to 1.0. Empirically, S=0.5 is generally effective.

The result is a better source match, which is shimmer-free and has some measure of sharpening. The match isn't perfect due to the approximated nature of the factor S [a deeper analysis might be worthwhile] and a little further sharpening is still needed. It causes few artefacts but it rarely repairs interpolation errors (e.g. when NNEDI3 mistakenly joins up lines). The process requires a second round of interpolation (e.g. NNEDI3) plus a second binomial smooth. In practice, you can use faster settings for the initial interpolation, and your desired settings for this basic source match pass.

Fine control of source match settings is left entirely to presets or there would be hundreds of settings. Basic source-match is enabled like this:

QTGMC( Preset="Slower", SourceMatch=1 )
QTGMC( Preset="Slower", SourceMatch=1, MatchPreset="Very Fast") # Tweak source-match interpolation settings (e.g. for NNEDI3)
# Default is 3 settings quicker than "Preset"

Refined Source-Match
You could chain together several iterations of the basic source-match method above in the hope that it would progressively refine to an ideal solution. However, subsequent passes make little headway. Instead, a slightly different approach is taken. Refined source-match takes the basic source-match output and again finds the difference between the original source fields and the updated fields. This time it interpolates the difference itself, then binomially smooths it, before adding it to the full-height output. This makes a small, but distinct step closer to the source. This method requires another interpolation step, but in practice a simple bob can be surprisingly effective. The better interpolaters are not really designed for difference images so it helps to pre-sharpen before this step to give them a more defined image to work on.

Twice Refined Source-Match
The refined stage above used another binomial smooth to avoid adding shimmer into the output. The second refinement uses the same formula as the basic source-match step to further correct the previous adjustment. This gets a tiny bit closer again to the source and also reduces the slight sensitivity to noise of the last step. This stage doesn't require an interpolation and is a worthwhile addition if using refined matching at all.

The refined source-match stages are enabled with SourceMatch = 2 or 3. There is another preset (MatchPreset2) that control their combined speed

QTGMC( Preset="Slower", SourceMatch=3 ) # Default basic preset is 3 settings quicker than "Preset", Refined preset is 2 settings faster again
QTGMC( Preset="Slower", SourceMatch=3, MatchPreset="Slow", MatchPreset2="Medium" ) # Force slower presets for source-match steps


Source-Match and Lossless
At this point we are very close to lossless: half the fields in the output are almost the same as the fields in the original source. The lossless steps simply copy the source fields directly into the output, where they now make a good match to the wholly generated fields. Where they don't quite match there will be residual combing. There is a little vertical cleaning (from original TGMCb2) that helps to clean that away. Artefacts are much rarer and less pronounced than previous versions. However, a different kind of shimmer problem can occur, since now half the lines are binomially smoothed and the other half aren't. The alternative lossless mode allows the injection of the original fields before the final temporal smooth to help mitigate this, at the expense of not being exactly lossless.

[pokazene_maslo]

Hello, first of all thank you for your great work!
I have read your explanations and I'm not sure if I understand them correctly.
I have 2 questions and one suggestion.

How to find out the correct sigma value? By using this QTGMC( Preset="Slow", ShowNoise=6.0, sigma=X) and adjusting sigma value until what is observed?
Is this the command to retain as much detail as possible while removing as much noise as possible?
QTGMC( Preset="Slower", NoiseBypass=1, NoiseRemove=1.0, NoiseRestore=0.0, Sigma=1.5 )
Suggestion: It is hard for an ordinary person to set up all parameters which control noise to get what he needs. What about introducing a "denoise=X" parameter, while X is a float value from interval (for example) <-1, 1> which would adjust TR2, NoiseBypass, NoiseRemove, DetailRestore, NoiseRestore, etc. at once while considering Preset for speed decisions.
So denoise=0 would mean output is as noisy as input, 1 would mean the strongest denoising, -1 would mean strongest noise amplification.
So the end user will get the best results by controlling only 2 parameters: denoise and sigma.

Once again, thanks for a great script!

[-Vit-]

I agree that there are probably too many noise controls now. I know the delicate effect of each, and will use all of them in different situations. But clearly that isn't easy for everyone else.

One simple piece of advice, NoiseRemove can almost always be 1.0. Because you can control the amount of noise removed with Sigma. One less setting to think about.

As to the other settings, there is a complex interaction between the different parts of the algorithm that determines their use. The defaults are a good starting point (use ShowSettings). Yet maybe I can simplify things with presets. I was careful to use presets with the new source-match feature. Let me think about that for noise in a later version.
___

ShowNoise: Adjust Sigma so you see noisy content, but not clean structural elements (edges). We want to make sure NNEDI3 gets everything that it can properly deal with, and that noise bypass gets anything that might be destroyed by the big temporal smooths. It's not an exact science though since NNEDI3 will have a go at any data you send it (and has probably seen noisy training data...), and the temporal smooths are not always destructive. Which is why the NoiseBypass=2 setting is there - send the noise down both routes...
___

Remove maximum noise, but keep maximum detail. An easy task then! Try:
QTGMC( Preset="Slower", NoiseBypass=1, NoiseRemove=1.0, DetailRestore=x, NoiseRestore=0, Sigma=1.5 )
Adjust DetailRestore=x downwards from 1.0 (maybe all the way to 0.0), until you're happy with the noise in the output. I simply cannot give you a value for x because that depends how sensitive you are to noise, which will be different to my sensitivity.

You could also try the same process, but set NoiseBypass=2, and start DetailRestore at 0.5. This might get you more detail.

[Didée]

Wow. That surely was lots of work. Respect!

Any thoughts about making the searchclip/processing better suited for mixed progressive/interlaced sources? :):)

* * * * *

BTW, now that the script is over 1000 lines and comes closer to 100 kB script size, I can't resist to post this - just for fun:

i = last
b = i.bob(.0,.5)
t = b.temporalsoften(1,255,255,25,2).merge(b,0.25)
s1 = t.blur(1.4).blur(1.4).merge(t,0.25).msuper()
s2 = b.msuper(levels=1)
b.mdegrain1(s2,s1.manalyse(isb=true),s1.manalyse(isb=false)).merge(b,0.25)
sharpen(.2,.8).repair(b,1)

The hard core of TGMC. Isn't it cute? ;)

[-Vit-]

Wow. That surely was lots of work.
This version only started as a little experiment a few months ago, but then it kinda snowballed... 1000 lines and half of them are comments! And still to add YUY2 and chroma speed-ups :eek:

Any thoughts about making the searchclip/processing better suited for mixed progressive/interlaced sources?
This does interest me as I have sources like that. Now I assume you mean without using some IsCombed variant, otherwise it's trivial. But then for each frame how do you know whether to bob-interpolate or not? There are [effectively] two frame rates in such sources. There may be a trick to it - I'll give it some thought.

The hard core of TGMC. Isn't it cute? ;)
Shall I add it...? Preset="Cute" :)
____

BTW: Just noticed that I've broken the "Draft" preset. That's not too important so I'll wait to see if there are any other issues before posting a fix.

[Boulder]

It would also be interesting to know whether there are good settings to use with fieldblended sources to get the good frames (output from SRestore, that is) as detailed as possible. The detection clip most likely needs to be treated in a different way from QTGMC.

Thanks for the new version :)

[elguaxo]

it would also be interesting to know whether there are good settings to use with fieldblended sources to get the good frames (output from srestore, that is) as detailed as possible. The detection clip most likely needs to be treated in a different way from qtgmc.

+1 :)

[-Vit-]

It would also be interesting to know whether there are good settings to use with fieldblended sources to get the good frames (output from SRestore, that is) as detailed as possible. The detection clip most likely needs to be treated in a different way from QTGMC.
I've had similar questions by PM. Unfortunately I don't work with fieldblended sources, and have barely used SRestore so I haven't looked at this issue. Maybe I'll get a chance to look at this, but I'm afraid it isn't a priority at the moment.

____

From some questions coming in I realize that despite that mass of detail earlier, I didn't properly address the practical issues of speed and memory. The new features require more memory and CPU time. They require you know how to run demanding scripts in avisynth. The defaults are tweaked for a particular balance of performance and quality, but you can tweak in either direction

Speed
Source-match performs 1 or 2 extra interpolations. So there are up to three interpolations per frame. The interpolators are determined by:
EdiMode="XXX" : the main interpolation, always occurs - nothing new here
MatchEdi="XXX" : Basic source match - for all source-match modes. Defaults to same as main interpolation, change if using a slow choice like "EEDI3+NNEDI3" as your main
MatchEdi2="XXX" : Refined source match - SourceMatch=2,3. Defaults to high speed NNEDI3. Can use "Bob" here with little penalty

Using "Bob" with SourceMatch=2,3 is a good performance boost for those modes:
QTGMC( Preset="Slower", SourceMatch=3, MatchEdi2="Bob" )

When using NNEDIx or EEDIx for source-match the interpolation speed can be tweaked. These default to much faster than the main preset:
MatchPreset="XXX" - typically "Fast" or quicker still
MatchPreset2="XXX" - typically "Very Fast" or quicker
____

Memory + Multi-Threading
Multiple NNEDI3s and complex QTGMC settings like noise bypass use memory. If you run out of memory you often get a crash. Use SetMemoryMax(XXX) at the start of the script to help. You might need higher values, or maybe lower, it depends on the source resolution, settings, SetMTMode use etc. - try 400,600,700,800,1000,1200...

Using multi-threading (SetMTMode) will help speed things up, but if you're on 32-bit avisynth you have a good chance of running out of memory if you go for very high settings, even on SD material, certainly on HD material. Again use SetMemoryMax, limit the number of threads in SetMTMode, and also use the EdiThreads setting of QTGMC - this last point is very important for source-match. 64-bit avisynth makes things easier - you still need to consider the same points, but you will have more latitude (depending on your machine).

An example multi-threading tweak to limit threads and allow a bit more memory, this is just an example, each case is different:

SetMemoryMax(700)
SetMTMode(5,4) # 4 threads for avisynth
WhateverSource(...)
SetMTMode(2)

# Three interpolations when using SourceMatch=2,3. Two defaulting to NNEDI3 here, plus a Bob. Set 2 threads for *each* NNEDI3
QTGMC( Preset="Slower", SourceMatch=3, Lossless=2, MatchEdi2="Bob", EdiThreads=2 )

[pokazene_maslo]

I'm trying to figure out how to use "ShowNoise". Whatever parameters I use, I get only plain grey picture, no detail, no noise. What am I doing wrong?
# Set DAR in encoder to 31 : 17. The following line is for automatic signalling
global MeGUI_darx = 31
global MeGUI_dary = 17
LoadPlugin("D:\Install\meGUIx64\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Download\VTS_01_1.d2v", info=3)
LoadPlugin("D:\Install\meGUIx64\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, interlaced=true, threads=0)

QTGMC( Preset="Slow", ShowNoise=8.0, sigma=2)

[Boulder]

I've had similar questions by PM. Unfortunately I don't work with fieldblended sources, and have barely used SRestore so I haven't looked at this issue. Maybe I'll get a chance to look at this, but I'm afraid it isn't a priority at the moment.Would you like to have a sample to look at? The problem with fieldblended material IMO is that the motion is not "real motion". The underlying source is basically always progressive.

[-Vit-]

I'm trying to figure out how to use "ShowNoise".
You need to enable noise bypass for this to work:
# I suggest you explicitly set NoiseDeint - it defaults to "DoubleWeave", "Generate" is best, you can also set "Bob"
QTGMC( Preset="Slow", NoiseBypass=1, ShowNoise=8.0, sigma=2, NoiseDeint="Generate" )
I suppose it should get switched on automatically if you set ShowNoise. I'll add that to the 3.01 version, which I'm using to fix all the inevitable minor issues like this.

____
Would you like to have a sample to look at?
It would be good to have a typical example of the problem from someone who deals with it. Still I don't expect to be able to look at this issue for some time...

[pokazene_maslo]

Heh :) I was assuming that it can set up all needed parameters automatically. Thanks.

Now I have another problem. I was trying to find appropriate sigma but I have found that I need to denoise also chroma planes to get good results. How it is with "plane=4" support? Are there needed any other changes in your script to get "plane=4" support?

[-Vit-]

Heh :) I was assuming that it can set up all needed parameters automatically. Thanks.

Now I have another problem. I was trying to find appropriate sigma but I have found that I need to denoise also chroma planes to get good results. How it is with "plane=4" support? Are there needed any other changes in your script to get "plane=4" support?
Sorry, it currently only denoises luma. That's temporary. There are quite a few changes needed to add chroma denoising, but it's the next version that will be focusing on the chroma planes. Maybe you should denoise as a separate step.

[dansrfe]

n00b question. Ok so I'm slightly confused. Does QTGMC work with fieldblended PAL material (with sresotore traling it) and if not then what other sources can it potentially fix?

[txporter]

n00b question. Ok so I'm slightly confused. Does QTGMC work with fieldblended PAL material (with sresotore traling it) and if not then what other sources can it potentially fix?

It can be used on fieldblended PAL material, but srestore needs to have another clip to detect the blended frames.

I use something like this for converting NTSC Torchwood/Dr Who/Robin Hood/etc DVDs:
setmtmode(5,0)
loadcplugin("C:\program files\avisynth 2.5\plugins\yadif.dll")
o = MPEG2Source("Torchwood.S1E01-clip.d2v",cpu=3)
setmtmode(2)
y = o.yadif(mode=1,order=1)
qtgmc = o.QTGMC(Preset="Ultra Fast",rep2=4,SLmode=1,SLrad=1)
qtgmc.Srestore(frate=25,dclip=y)

[kutjong]

I'm currently trying to repair some material that was sloppily converted from interlaced to progressive using what seems to be weave deinterlacing (lots of combing artifacts).

So far, I'm using this:

QTGMC( Preset="Slower", InputType=2, ProgSADMask = 10.0, SourceMatch=3, Sharpness=0.4, TR2=3 )

This makes substantial repairs, but there are still some combing artifacts in few frames.

Are there any other variables that I should experiment with?
I've read the documentation but embarrasingly most of it is just way over my head. :)

[-Vit-]

I'm currently trying to repair some material that was sloppily converted from interlaced to progressive using what seems to be weave deinterlacing (lots of combing artifacts).

So far, I'm using this:

QTGMC( Preset="Slower", InputType=2, ProgSADMask = 10.0, SourceMatch=3, Sharpness=0.4, TR2=3 )

This makes substantial repairs, but there are still some combing artifacts in few frames.

Are there any other variables that I should experiment with?
I've read the documentation but embarrasingly most of it is just way over my head. :)

That's a good start. Simplest thing to do is lower ProgSADMask, potentially to 0.0.

InputType=2 tries to rebuild a shimmer-free result from the even lines (fields), InputType=3 does the same using the odd lines. Each loses detail from the other lines. The following script runs both modes. It means some redundant processing, but it does improve detail and reduce artefacts:

c = WhateverSource("Your.src")

# Two versions of fixed source (use TR2 and ProgSADMask also if you wish)
t = c.QTGMC( Preset="Slower", InputType=2, SourceMatch=3, Sharpness=0.4 )
b = c.QTGMC( Preset="Slower", InputType=3, SourceMatch=3, Sharpness=0.4 )

# Now merge the results in some way. Choose ONLY ONE of the lines below and delete the other
Merge( t, b ) # Smooth result, may need more sharpening
t.Repair( Merge( t, b ), 1 ) # Sharper result, could try 2 at end of this line
There are almost certainly even better ways to merge the results, this was just a quick idea...

One of the minor fixes I'm sitting on at the moment in version 3.01 is allowing Lossless modes for InputType=2,3. That helps with detail, but I guess that's not your problem.
____

You can do some serious script abuse by chaining together progressive QTGMCs. Generally it's not a good idea because the repeated motion compensations are both redundant and drift in accuracy which causes smearing. You also get gradual over-sharpening. [Although sensible uses like the one above makes me think a toolbox approach might be beneficial]

So another approach for your situation, that I don't recommend but you might want to try, is to run a QTGMC( InputType=1 ) on the result of your QTGMC( InputType=2 ). It will certainly clean up the artefacts, but it may cause smearing / oversharpening:

QTGMC( Preset="Slower", InputType=2, SourceMatch=3, Sharpness=0.4 ) # Plus any other settings
QTGMC( Preset="Slower", InputType=1, Sharpness=0.1 ) # Don't use source-match here

[AnXioZ]

Excuse me for the n00b question but, do I loose any vertical resolution if I decide to keep the framerate of the interlaced source? In example, I have a 1080i60 (60 fields/s | 59.94 frames/s playback) bluray source, and I want to encode it to 1080p60 (59.94 frames/s). In my experiments I haven't seen any noticeable decrease in quality after deinterlacing, but I just wanted to know of the side-effects.
Thank you in advance.

[osgZach]

one field is thrown away, and the data from the other is used /interpolated to keep the same resolution, if I recall correctly. That's how it usually works. What you see is what you get basically... So if you are previewing and choose same rate deinterlacing, and you see the same image size as the source, then that is what you get ;)

[-Vit-]

No, you won't really lose any resolution. Deinterlacing effectively increases vertical resolution.

Put simply: your 1080i60 source is really a 60fps stream of 540 pixel high images (fields). Each pair of fields is interlaced (weaved) into a single 1080 pixel high frame, resulting in a 30fps stream of interlaced frames. Deinterlacing separates the fields again and doubles their height to give a 60fps stream of true 1080 pixel high frames. Compare with the starting point: the vertical resolution is increased.

The new pixels are created by intelligent interpolation of other pixels in the same field and pixels in neighboring fields. No fields are thrown away during this process. If you decide to drop half the frames after deinterlacing to keep the original 30fps rate, that's fine - no quality is lost on those frames you keep.

The original fields in your source are sometimes altered a little in the deinterlaced output to ensure that the result is smooth and shimmer-free. But there should be very little detail loss (especially with the latest features). In fact, the newest developments mean the doubled height output can make a good estimate of lines that are not actually stored in the source. That's what the Source_Comparison example (http://www.mediafire.com/?6kcahljmqizr9mj) was showing in my earlier post (http://forum.doom9.org/showpost.php?p=1474061&postcount=159). This compares a source recorded with 720 pixels of vertical resolution against a QTGMC deinterlacing of 360 pixel high fields (i.e. I deliberately threw away half the pixels and got QTGMC to try and work out what they were)

[AnXioZ]

Thank you for the input guys. Much appreciated.

No, you won't really lose any resolution. Deinterlacing effectively increases vertical resolution.

Put simply: your 1080i60 source is really a 60fps stream of 540 pixel high images (fields). Each pair of fields is interlaced (weaved) into a single 1080 pixel high frame, resulting in a 30fps stream of interlaced frames. Deinterlacing separates the fields again and doubles their height to give a 60fps stream of true 1080 pixel high frames. Compare with the starting point: the vertical resolution is increased.

The new pixels are created by intelligent interpolation of other pixels in the same field and pixels in neighboring fields. No fields are thrown away during this process. If you decide to drop half the frames after deinterlacing to keep the original 30fps rate, that's fine - no quality is lost on those frames you keep.

The original fields in your source are sometimes altered a little in the deinterlaced output to ensure that the result is smooth and shimmer-free. But there should be very little detail loss (especially with the latest features). In fact, the newest developments mean the doubled height output can make a good estimate of lines that are not actually stored in the source. That's what the Source_Comparison example (http://www.mediafire.com/?6kcahljmqizr9mj) was showing in my earlier post (http://forum.doom9.org/showpost.php?p=1474061&postcount=159). This compares a source recorded with 720 pixels of vertical resolution against a QTGMC deinterlacing of 360 pixel high fields (i.e. I deliberately threw away half the pixels and got QTGMC to try and work out what they were)

Thank you for the great expiation -Vit-, and thank you for the great work!

[AnXioZ]

Hey -Vit-, I just installed the new 3.0 version. I am still playing around with it, but one thing I noticed was that when I set SourceMatch=3 the CPU utilization drops significantly. Without it I'm getting ~98% utilization, with SourceMatch I'm getting ~70%. Am I doing something wrong or is that expected with the new enchantments?

[-Vit-]

CPU under-utilization often means that there are cores idle on a multi-core machine. E.g. One core is busy running a key step in the script, another core is trying to run a task that needs the result - if there are no other tasks to do then the second core idles (it's rather more intricate than that, but you get the idea). Run more threads, give your cores more to do. Run multi-threaded using SetMTMode, or increase the thread count if you're using it already. I posted some tips on that a few posts ago in this thread. Also NNEDI3 runs two or three times with source-match and NNEDI3 defaults to running multi-threaded. You can tweak its thread usage with EdiThreads=x. Try tweaking x, it might help (or not).

[osgZach]

Silly question if you don't mind. If I feed it a progressive clip, is it going to make a "this is combed" decision and skip frames, or is it going to process every single frame in the clip?

There is a lot of material to read through, so I'm sorry if this was asked/answered before. I'm generally interested in using it to clean up IVTC'd material where the stream result is progressive obviously, but sporadic combing will occur. I could see using this for Clip2 operations, but if it doesn't do "needless" processing where there is no combing, it may be easier to just throw it on at the end of the script in some cases.


edit: ok, its runs about 15 fps using "QTGMC( Preset="Medium", InputType=1 )" which is realistically fine I guess.. It seems to be pretty much identical to the source. So ignoring the fact I am deliberately slowing my script down more than I -need- to. If I wanted to use TFM and set PP to 0 (don't hint, don't attempt to deinterlace) and then just tack QTGMC on at the end, to catch and fix any combing (surprisingly I couldn't find any real combing but I used the most intensive match mode so thats probably why.) It would be a valid and correct usage, right? I just hate tweaking thresholds and all that stuff so I'd take a time increase vs having to tweak per file all the time.

I'm sure I could adjust a few things to make it go faster and not ruin the quality, too.

[-Vit-]

The script makes no attempt to detect combing. It runs a temporal binomial smooth on every frame to remove bob-shimmer when deinterlacing. This same process is also effective in remove deinterlacing residue from progressive video. But it isn't selective on which frames to process. I've seen others run a QTGMC in your situation, but it's not a workflow I need so I can't really comment further.

[osgZach]

Fair enough. If anyone else has been using it for this purpose, I'd be interested to hear their take as well.

[Didée]

What kind of "residual" combing? Low-value combing (from mpeg compression, because the matched fields come from different coded frames)? Or fully interlaced frames because of lone fields that couldn't be matched?

Because - when I hear (or see) "residual combing", my first thought is "vinverse". Not "QTGMC". ...

[osgZach]

Oh jeezus Didee, you scared me for a second. I thought I said "residual combing" somewhere and used the wrong term.. Bad Didee!

To Clarify: I am simply talking about combing left in frames either from doing no post-processing whatsoever (TFM PP=0), or combing that was not picked up after field matching for whatever reason (Mic below threshold, etc).. I'm not a "tweaker" at heart, I prefer "run it once and its done" operations, I guess. So I was just inquiring if it were a proper use or not. McBob/TGMC are just too slow for me, but QTGMC seems to be fast enough I don't mind waiting as much.

IIRC AnimeIVTC uses Vinverse doesn't it? I have always been curious about it but its options have always been a little intimidating (no offense). And seems like "more tweaking" for this "non-tweaker at heart" :p

[maki]

What settings should I use to decomb and deinterlace this (http://www.megaupload.com/?d=O8YWB61Q) progressive content. I also want to remove noise/dirt artifacts that appear around the lips, that's pretty much the only place where they appear.

I noticed that deinterlace/jaggy lines and noise only appear when I downsize the video to 720p.

I am new to the whole decoming and deinterlace in a video. And I don't really understand the difference between jagginess and deinterlace. Can someone explain it to me. I've read about it but I don't really get it.

Also I applied this plugin to the video and it seems that coming appears in every frame:

http://img15.imageshack.us/i/piczb.png/

AVCSource("C:\00007.track_4113.dga")
FieldDeinterlace(full=true, map=true)
LanczosResize(1280,720) # Lanczos (Sharp)
Trim(29560, 31846)
#deinterlace
#crop
#denoise
ConvertToYV12()

Can someone give me some nice settings to fix all of the above.

[Fullmetal Encoder]

Has anyone had any success getting the Very Slow preset, with or without any variations, to work with any speed/stability using 3.0 on a Core i7+ system? At this point I've run 44 different tests in which I've altered SetMTMode and SetMemoryMax and every test produces either less than 1fps output (usually much less) and/or crashes. Varying EdiThreads doesn't seem to have any effect. The basic script I am using is:


SetMemoryMax(700)
SetMTMode(5,4)
Import("C:\QTGMC3.0.avsi")
LoadCPlugin("F:\ffmpegsource-2.14-mt-avs64\ffms2.dll")
FFVideoSource("D:\X.mkv")
SetMTMode(2)
Trim(1753, 3542)
QTGMC(Preset="Very Slow", MatchPreset="Medium", SourceMatch=3, Lossless=2, MatchEnhance=0.6, Sharpness=0.25, NoiseBypass=2, NoiseRemove=1.0, DetailRestore=0.5, NoiseRestore=0.1, Sigma=3, NoiseDeint="Generate")

The MKV I'm using as a source is an interlaced 1080P clip. I realize the QTGMC settings I am using are rather aggressive but they are an example that I believe -Vit- posted previously. What I am trying to accomplish is to determine a set of very high quality, nearly lossless settings which are still functional, to then tweak the Avisynth settings to see how high I can push output performance, and then to do some quality comparison tests on various clips to determine whether it's worth it to stick with those settings or reduce quality in exchange for speed. I am using JoshyD's (04/16/2010) Avisynth on a Core i7 860 with Windows 7 Professional 64-bit and 8GB of RAM.

Using similar QTGMC (slow, very slow) settings which Avisynth settings give you the best performance? What kind of system are you running? So far, all I can conclude is that it's either impossible to run the above QTGMC settings on any modern system or that there is something seriously wrong with my set-up.

[Didée]

Way too complex for 1080 video. Are you even halfway aware of the amount & kind of operations that QTGMC is doing with these settings?

Running single-threaded, SetMemoryMax(1200) gives me 0.25 fps. SetMemoryMax(1400) gives 1.1 fps, however Vdub now has peaked at 1.85 GB. SetMemoryMax(1440) loads, but crashes upon seeking. Of course, such memory load doesn't allow for e.g. direct x264 encoding. I don't get the script to run using 4 Threads via SetMTmode(2), even setmmax(500) throws kernelbase after a few frames.

Way too complex for 1080 video. And breaking a fly on a wheel, anyway.

[-Vit-]

I designed the settings to make a steady gradient from "as fast as possible" to "unnecessarily accurate". The slowest settings are all about ultimate precision and completely ignore speed as a factor. Also, none of the presets take any account of resolution, so you need to. Settings like yours are visually great for big upscales on SD, but unless you have a huge display, you simply won't see the difference at the very slowest settings at HD resolutions.

If you must get it to run, a 64-bit workflow is required (check) and with regards threading work upwards from 1 main thread + 1 EdiThread. I find having EdiThreads lower than main threads helps on my system (I use a 12Gb i7 930 and a similar 950). Render lossless, do your x264 in a second pass.

Regarding tweaks other than the presets, you can get a speed boost from MatchEdi2="Bob". Also NoiseDeint="DoubleWeave" will be faster and might make little difference, depending on your source. Make sure your SetMemoryMax is tweaked - wrong setting there can slow things down. Check the presets table in the script for other ideas.

From my experience, the stability problems come from three points:
(a) Memory issues: 32-bit avisynth running out of memory (overeager / buggy caching?), the black art of SetMemoryMax, leaky plugins - thankfully these issues are less noticable on 64-bit
(b) Buggy plugins: many plugins inherit threading issues from avisynth (see below), but some have other bugs too. At this very moment I'm rewriting AddGrainC from scratch because I think it is causing crashes for me, I can almost guarantee a crash if I try very complex HD scripts with NoiseDeint="Generate" (uses AddGrain), and I don't get them without. This may be your problem. Try setting NoiseDeint="DoubleWeave" or NoiseBypass=0.
(c) Avisynth multithreading. In early experiments with QTGMC I had serious problems with crashes on 1080p even at medium settings. Traced the problem to the avisynth<->plugin threading (synchronization problems with ref counts usually). SEt has fixed some of these in his MT avisynth builds, but they affect "avisynth.h" which needs to be compiled into all the QTGMC plugins. I've done that with all the 32-bit versions and also added a hideous hack of my own, and it helped a lot. However, I still need to resolve a few issues with the 64-bit versions and test a bit more before I could post them (all VS2010 and IC2011 - some conversion issues need checking).

So even if you can get a speed you can live with, it's certain that as your resolution and script complexity increases, so does your chance of avisynth instability. I have had to tone down scripts from the level I wanted because of this in the past.

[Fullmetal Encoder]

Way too complex for 1080 video. Are you even halfway aware of the amount & kind of operations that QTGMC is doing with these settings?

Running single-threaded, SetMemoryMax(1200) gives me 0.25 fps. SetMemoryMax(1400) gives 1.1 fps, however Vdub now has peaked at 1.85 GB. SetMemoryMax(1440) loads, but crashes upon seeking. Of course, such memory load doesn't allow for e.g. direct x264 encoding. I don't get the script to run using 4 Threads via SetMTmode(2), even setmmax(500) throws kernelbase after a few frames.

Way too complex for 1080 video. And breaking a fly on a wheel, anyway.

Ok, thanks for the feedback. Yes, I know it is quite complicated and while I understand some of the basics of what it's doing I am not aware of its intricacies, especially when it comes to its use of mvtools and masktools, so probably, no :) Just wanted to get some input from others before proceeding with any other testing in case it would end up being a waste of time. And throughout my testing I have started to get the impression that what I was attempting to do was really to kill a mosquito with a bazooka.

The more I read up on this plugin though the more impressed I am with what it's able to do so thanks to -Vit- for his work on it and to you Didée for the underlying TGMC.

[Didée]

The "most important" application IMHO is on SD content, anyway. When SD content is cheaply bob/deinterlaced and viewed on a big screen, then you'll see the downsides from bad deinterlacing in all glory, because the upscale makes everything more objectable.
On 1080i, this is so much less of concern, because no upscale is taking place. Even the "simple" deinterlacers result in an acceptable viewing experience. If I personally use Q/TGMC on 1080i, then it surely is with pretty fast settings. Even the most simplistic settings give like, say, 80% of what Q/TGMC can achieve. And those 80% are already way ahead of what other deinterlacers can achieve. See this older sample (http://www.mediafire.com/?s23960xpv9wz318) from 1 year back: old TGMC with most-fast and most-basic settings, versus YadifMod with NNEDI2 interpolation. TGMC was much faster, still it let Yadifmod/NNEDI2 stand with egg in their face.

[TheSkiller]

Thanks for the new version, just tried it - looks great with the new SourceMatch on my MiniDV stuff.
But with another type of source that requires rep0=0 there is something odd I noticed: whenever I use any of the lossless modes, especially without SourceMatch (SourceMatch=0) I pretty much always have combing left in the output. With version 2.51 this was not the case (version 2.51's fake lossless "Lossless=1" was free of remaining combs for me).

I also find the fake lossless mode to have a lot more remaining combing than the true lossless mode Lossless=1 (which doesn't make sense), even with the default rep0=4.


Edit: Sorry, forgot to add: I'm using rep0=0 because otherwise static parts (Text) laying on top of the motion would have an ugly up and down bobbing occasionally on this source (is there a better way to fix this?). The described problem with combing never occurs with rep>0, and never with QTGMC 2.51.

Edit: cleaned my post, got messed up somehow.

QTGMC(2,2,1, 0,0,4, Lossless=2, SourceMatch=0) #lots of combs (but steady text)

[STC-Fan]

Tried this out today with one of my PAL VHS captures - really impressed with it. Using QTGMC with just the "Slow" preset has produced a massive improvement when compared with my current filter choice in AviSynth, which is MDegrain2i2 + Cnr2k + Yadif.

My only problem now is that I get a Visual C++ runtime error along the lines of "This application has requested the Runtime to terminate it in an unusual way", which happens after a short while when I try to do a 2-pass encode with x264 in MeGUI, which I am guessing is down to the program running out of memory.

I've only tried SetMemoryMax() with a value of 512 so far, and that hasn't resolved the problem. Presumably, I will need to increase the value to 1024 or more, and close Firefox when the encode is running along with any other programs.

Before it crashed, I was getting around 5.6 FPS on the first pass, which is fairly reasonable. I'm a bit surprised that even with SetMTMode(2) that I can't get more on a Core 2 Quad Q6600 - I suppose I could try a faster mode in QTGMC, or get myself a computer with a bit more power; I'm thinking along the lines of something from Cray, to be honest :P

I put up some comparison screenshots and sample scripts - the best thing is the reduction of jagged edges on the graphics, which the old trio of filters couldn't really do much about:

Original frame (http://stc.hacking-cult.org/videos/avisynth/bbc1_advert_original.png) | AviSynth script (http://stc.hacking-cult.org/videos/avisynth/bbc1_advert_original.avs)

MDegrain2i2 + Cnr2k + Yadif (http://stc.hacking-cult.org/videos/avisynth/bbc1_advert_mdegrain2i2+cnr2k+yadif.png) | AviSynth script (http://stc.hacking-cult.org/videos/avisynth/bbc1_advert_mdegrain2i2+cnr2k+yadif.avs)

QGTMC 3.0, Slow preset (http://stc.hacking-cult.org/videos/avisynth/bbc1_advert_qtgmc3-slow.png) | AviSynth script (http://stc.hacking-cult.org/videos/avisynth/bbc1_advert_qtgmc3-slow.avs)

Overall, though, it's a very good script, this - I think that QTGMC3 could even be better than Cillit Bang / Easy-Off BAM :)

[-Vit-]

...there is something odd I noticed: whenever I use any of the lossless modes, especially without SourceMatch (SourceMatch=0) I pretty much always have combing left in the output.
Some of what you say doesn't surprise me - it's a very intricate script now and I may have overlooked some combinations of settings. However, I don't get more combing with "fake" lossless than "true", the only difference between those modes is when they occur in the script, before or after the final smooth. Still, I'll have a look at the rep modes and see what I find...

Visual C++ runtime error
I listed the range of things that causes stability issues a couple of posts above. I also posted some notes on performance and MT use (http://forum.doom9.org/showthread.php?p=1474231#post1474231). One other important thing I note in the OP is using the right version of AviSynth. I can only get extended stability with SEt's 2.6MT (http://forum.doom9.org/showthread.php?t=148782). Make sure all your other plugins are up to date too. A SetMemoryMax of 512 should be OK for Preset="Slow" alone (provided your overall RAM is not low), but maybe tweaking it might help. Sometimes it needs to be lowered.

If you do get it stable, try tweaking the thread-count as described in that overview I mentioned. You may get better speeds with more or less threads.

[matfra]

I have a basic question for you.
MT("""
QTGMC(tr0=0,tr1=1,tr2=0,EdiMode="nnedi3",rep0=4,rep1=0,rep2=4,sharpness=1.00)
""",threads=4, overlap=4)

Is it the best way to run this script with MT ?
Also what is SetMemoryMax(). Does it really speed up the encoding ?
Merci !

[matfra]

Im wondering if its better to apply some denoising and sharpening in with QTGMC, or if its better to apply a simple Deinterlaced, then denoise and sharpen after.

What do you recommand guys ?

[Boulder]

I listed the range of things that causes stability issues a couple of posts above. I also posted some notes on performance and MT use (http://forum.doom9.org/showthread.php?p=1474231#post1474231). One other important thing I note in the OP is using the right version of AviSynth. I can only get extended stability with SEt's 2.6MT (http://forum.doom9.org/showthread.php?t=148782). Make sure all your other plugins are up to date too.For some reason, I've had much better stability using tsp's last MT build of Avisynth 2.5.7. For two weeks I played around with SEt's two builds but was never able to finish an x264 encode or encode to lossless intemediate file without Avisynth crashing. (For what it's worth, I had a script with Deblock_QED + MCTemporalDenoise in it).

[-Vit-]

@matfra

You should not use MT("...") with QTGMC, you should use SetMTMode(...). SetMemoryMax is not a speed-up generally - it sets a balance of memory for your script to work - you might not need it.
Here is a template script, adjust it as you need:

SetMemoryMax(700) # This line may not be necessary - depends on your settings, number of threads and available memory. Try 400,600,700,800,1000,1200...
SetMTMode( 5, 4 ) # Use 4 threads, adjust to suit your machine
WhateverSource(...) # FFVideoSource, DGDecode_mpeg2source, AviSource, whatever your source requires
SetMTMode(2)

QTGMC( ... , EdiThreads=2 ) # Set number of threads for NNEDI3 (more or less than setting above), add any other settings you require


QTGMC provides some sharpening and denoising control, but only you can decide if it is good enough, or if other processing is needed. In other words, try it both ways and decide for yourself which is better.

[ajp_anton]

Is it a good idea to merge this with MCTemporalDenoise into one single giant function so that MCTD can re-use the motion vectors from QTGMC?

[STC-Fan]

I listed the range of things that causes stability issues a couple of posts above. I also posted some notes on performance and MT use (http://forum.doom9.org/showthread.php?p=1474231#post1474231). One other important thing I note in the OP is using the right version of AviSynth. I can only get extended stability with SEt's 2.6MT (http://forum.doom9.org/showthread.php?t=148782)

Thanks for that - I've actually been able to resolve the biggest issue (slow speed encoding leading to a crash) by reverting back to using MT mode 5 before AVISource, then using MT mode 2 for QTGMC and other plugins. In fact, I'm now getting nearly 12 FPS for first and second passes - not 16 or 20 like with MDegrain2i2, but the payoff in restored detail and better correction of interlacing artifacts etc. is well worth it :)

As for the memory running out - on the last script I ran for a 6-minute video, I increased SetMemoryMax to 768 and this has eliminated crashes for the time being. However, I have recently had BSOD crashes with the MEMORY_MANAGEMENT error on Vista (SP2), so I might need to run the memory checker and possibly replace the RAM I have.

The other filter I sometimes use is fizick's DeFreq for removing RF (diagonal line) noise, so I'll check and see if that will work harmoniously with QTGMC.

EDIT: poisondeathray - my source video is all TFF, I have tested your suggestion and the 50 FPS output from QTGMC is now nice and smooth, thanks for the tip! The equivalent settings I used for Yadif were mode=1 (double framerate) and order=1 (top field first).

I've also tested the output on some more noisy VHS clips which need DeFreq (placed before QTGMC) and they looks very nice as well. With those clips (thankfully only a few) there is still a small amount of background noise crawl and feint horizontal lines, although in the final output from x264 much of this isn't really visible anyway. Probably I could mess around a bit with QTGMC's parameters in detail, beyond the standard Slow preset, but I'm more than satisfied with the results at the moment :)

UPDATE: I've had a look at some stronger denoising to go with the detail restoration / deinterlacing from QTGMC. I've found that for my VHS content, I can get better results by using the MDegrain2i2 function before QTGMC(Preset="Slow") - normally I would just use one or the other. With both of these in one script, they work extremely well together, though it does hit encoding time to x264 somewhat (down to about 6.5 FPS instead of 12 FPS with just QTGMC @ Slow). Despite this, the results are definitely worth it. I have uploaded some standard size screenshots, 4x magnified sections of those screenshots and my most recent AviSynth scripts here:

QTGMC + MDegrain2i2, QTGMC alone and MDegrain2i2 alone (http://stc.hacking-cult.org/videos/avisynth/AviSynth-QTGMC_vs_MDegrain2i2_06-11-2011.7z)