QTGMC Deinterlacing Script (v3.32)

[yup]

To all interested about support YUY2.
For all Avisynth build (2.58, 2.58 MT, IanB 2.6, SEt 2.6) will be properly work only mt_masktools-25***.dll, because mt_masktools-26***.dll need YV16 planar colorspace (not from Interlevead2Planar).
see http://forum.doom9.org/showthread.php?p=1497883#post1497883
If we want use 26 masktools we could work with 3 types colorspace YUY2, hacked Kassandro (Interleaved2Planar) and native YV16 it is ridiculous.
yup.

[Heaud]

I've been getting errors running QTGMC 3.31 when using qtgmc("slow", shutterblur=2, fpsdivisor=2) or any other faster preset. The error displays as "super clip does not contain needed color data". Could this be due to that slight speedup in a previous version?

[-Vit-]

I've been getting errors running QTGMC 3.31 when using qtgmc("slow", shutterblur=2, fpsdivisor=2) or any other faster preset. The error displays as "super clip does not contain needed color data". Could this be due to that slight speedup in a previous version?
Well spotted and the correct reason, thanks. I've updated the first post (http://forum.doom9.org/showthread.php?t=156028) with a fix (v3.32). There are some other very minor changes in there as well.

[K1CS1K]

Hy All!

I'd like you to check some of my footages and give me some advice. :)
I use QTGMC mainly for deinterlacing video game materials and I'd be glad if you could help me in some ways.

I've uploaded a .zip file here (http://www.megaupload.com/?d=QVAW11IQ) including the following files:

-3 .avs files (details below)
-source file (150 frames), UtVideo codec (in this case ULY0 due to QTGMC's obvious colorspace requirements)
-a test conversion with my script I normally use (x86 edition, with my PC it required 38m52s)
-a test conversion (x64) with the same specs I use in the .avs for x86 (12m1s but because of the quality loss and huge 'artifact' problem or something, I don't know what to call this deterioration of the frames)
-a test file (x64) with modified specs from my x86 .avs (35m35s ; see 'x64 without Blocksize & Overlap.avs' below)
-last test material (x64) with VirtualDub x86 (23m46s & exact filesize as x86's ; somehow x86 & x64 avisynths were installed at the same time but independently, Windows\System32 contained only 32-bit files for the process)

For all normal 64-bit conversions I used Veedub64 and in every case the output codec was ULY2 (in my opinion it's the fastest and makes the best possible results after the 'almighty' raw uncompressed; after a few identical tests it was waaay much faster than using the uncompressed output format in this case of ). All the 64-bit and 32-bit plugins needed for QTGMC are the latest, I can list them with the version numbers if you would like to. When I first met QTGMC, I read literally all the intructions in the QTGMC.avsi (now we know it's separated into 2 files) and after that I started to use these following avisynth scripts I found the toughest :

x86.avs:

SetMTMode(5,0)

AVISource("test.avi")

QTGMC( Preset="Placebo", NNeurons=4, EdiQual=2, Sharpness=0.25, SubPel=4, Blocksize=32, Overlap=16, SourceMatch=3, MatchPreset="Placebo", MatchPreset2="Slower", MatchEnhance=0.6, Lossless=2, Sigma=3, GrainRestore=0.5, FPSDivisor=2, ChromaMotion=false )

--------------------

x64.avs (the same as the x86 edition above but contains redirection to 64-bit plugins after installing avisynth64):

SetMTMode(5,0)

AVISource("test.avi")

SetWorkingDir("c:\Program Files (x86)\AviSynth 2.5\plugins64")

QTGMC( Preset="Placebo", NNeurons=4, EdiQual=2, Sharpness=0.25, SubPel=4, Blocksize=32, Overlap=16, SourceMatch=3, MatchPreset="Placebo", MatchPreset2="Slower", MatchEnhance=0.6, Lossless=2, Sigma=3, GrainRestore=0.5, FPSDivisor=2, ChromaMotion=false )

--------------------

x64 without Blocksize & Overlap.avs (after removing these specs from the script, the image became as clean as it should be):

SetMTMode(5,0)

AVISource("test.avi")

SetWorkingDir("c:\Program Files (x86)\AviSynth 2.5\plugins64")

QTGMC( Preset="Placebo", NNeurons=4, EdiQual=2, Sharpness=0.25, SubPel=4, SourceMatch=3, MatchPreset="Placebo", MatchPreset2="Slower", MatchEnhance=0.6, Lossless=2, Sigma=3, GrainRestore=0.5, FPSDivisor=2, ChromaMotion=false )

--------------------

Usually for normal length gameplay videos (4-5 mins) the average conversion speed is 0,25fps with my PC & the .avs files above.

Please help me in improving my script and make the best out of the source material. ;)

Thanks in advance,
K1CS1K

Our YouTube channel (http://www.youtube.com/K1CS1K)

[-Vit-]

That source is not interlaced. It's progressive that has been weaved strangely. One field of each frame exactly matches the other field of the next frame. A capture issue maybe? Anyway, no deinterlacing is needed:

AviSource( "YourPathTo\test_150_frames.avi" )
ComplementParity() # Might not always need this line
SeparateFields().Trim(1,0).Weave()


The source is sampled strangely horizontally, as though every 7th and 8th column have been swapped. That is either my decoder (I rarely use Ut), or it might be your emulator, capture process, encoder or something... You would need to fix the problem component or write a custom script if the problem is at your end.

You might prefer the look of your encodes because the QTGMC temporal processing smooths things a little. However, QTGMC is not the right tool for this job. [Those QTGMC settings were overkill for any source. MatchPreset="Placebo" is never worth it.]

[nhope]

-Vit-, I re-labelled the preset tables "3.32". You can all sleep soundly again now.

[egrimisu]

maybe it's out topic but shall i compress with qtgmc using selecteven if i want to deinterlace a pal dv source. I want to transfer it to dvd but i'm not sure if dvd players are compatible with pal 50fps progresive. Hope you cand help.

[Boulder]

I think you might want to experiment with the single-rate output options in QTGMC instead of using QTGMC+SelectEven. You could get a more film-like appearance to the result.

[egrimisu]

so basicly that means that i can't use 50fps in a pal dvd. i haven't found any single-rate option in qtgmc, plese guide me.

[Boulder]

You cannot use 50fps streams for DVD. See the "Shutter Speed Motion Blur / Frame Rate" section in the QTGMC documentation, that's where the magic is.

[egrimisu]

You cannot use 50fps streams for DVD. See the "Shutter Speed Motion Blur / Frame Rate" section in the QTGMC documentation, that's where the magic is.

does the hardware dvd player know how to decode 25fps interlaced into 50fps full temporal resolution? i mean a lot of anime dvd are compressed like that, but i don't have a hardware player to test it, pc software player just blend frames.

[kypec]

I assume every standalone DVD player knows how to deinterlace 50i -> 25p if the source is in MPEG2 alias original DVD-Video format. If you are going to use MPEG4 ASP (Xvid, DivX) then your best bet is to deinterlace with QTGMC and encode as 25p -> please see the QTGMC documentation that Boulder had suggested.

[egrimisu]

I assume every standalone DVD player knows how to deinterlace 50i -> 25p if the source is in MPEG2 alias original DVD-Video format. If you are going to use MPEG4 ASP (Xvid, DivX) then your best bet is to deinterlace with QTGMC and encode as 25p -> please see the QTGMC documentation that Boulder had suggested.

Hi and thanks for the answer, but my question was if the dvd player can convert 50i to 50p (like qtgmc does). Thanks

[Boulder]

If you encode PAL content for viewing on the DVD player, you have to have the framerate at 25fps but you can either encode as interlaced or progressive. If the material is flagged as interlaced, the player will deinterlace on the fly (EDIT: and output at 50fps). That's why I would go for the QTGMC route, unless you want to keep the fluid motion of truly interlaced content.

[Didée]

A DVD player does not need to deinterlace anything. Decode picture, send picture to display, job done. Okay, the player needs to be able to do split the fields and to re-combine them (to obey RFF flags), but the player does not need [to be able] to perform deinterlacing. That's the job of the display device.

Of course, nowadays HW DVD players often do offer lots of additional functionalities, but that's all optional and varies between different devices. Per DVD standard, the requirements are little. Keep in mind back when the DVD standard was made, all display devices were interlaced CRTs. :)

[egrimisu]

If you encode PAL content for viewing on the DVD player, you have to have the framerate at 25fps but you can either encode as interlaced or progressive. If the material is flagged as interlaced, the player will deinterlace on the fly (EDIT: and output at 50fps). That's why I would go for the QTGMC route, unless you want to keep the fluid motion of truly interlaced content.

Now thing are pretty clear now, thanks, so any pal device output 50fps(i believe because the displays are at 50hz) ( if the source is 25fps progressive every frame will be doubled.
if my source is 25fps avi usig dvsd codec, video is interlaced but when i compress it to mpeg 2 i shall mark it as interlaced and then the hardware player will do the rest.

[dcrht]

There is no SSE3Tools for 64 bit avisynth so I couldn't import YUY2 videos. :(

[smok3]

any recommendations of the type of virtual machine to run such scripts in? is virtualbox working well with MT versions? should i find a copy of 64bit windows? ect.. (curently i'am strugling a bit with parallels, host is OSX)

does the hardware dvd player know how to decode 25fps interlaced into 50fps full temporal resolution? i mean a lot of anime dvd are compressed like that, but i don't have a hardware player to test it, pc software player just blend frames.

anime at 50fps? i thought they are more like 2fps...

[Anakunda]

Hello, how do I implement QTGMC with StaxRip, is it enough to copy all support plugins + QTGMC-3.32.avsi into Avisynth\plugins dir, then replace YaDiff() with
QTGMC( Preset="Slow" )
SelectEven()
or is it more complicated?
Do I have to #include QTGMC-3.32.avsi first somehow, or is it autoloaded by AviSynth?
Thanks!

If I omit SelectEven(), then the result framerate is doubled, ie. for 25fp=>50fps? 50fps comes me quite overkill for an human eye, please explain.

[SubJunk]

50fps comes me quite overkill for an human eye, please explain.24-25fps is the past (http://www.spirton.com/james-cameron-george-lucas-and-peter-jackson-want-higher-framerates/), another link (http://www.digitaltrends.com/entertainment/director-peter-jackson-the-hobbit-is-shot-at-twice-the-normal-frame-rate/)

[Anakunda]

Ok let's move to high framerates. Do twice the framerate necessary mean doubled bitrate?
now I struggle with the speed. At Preset="slower" the encoding speed is really slow and I see CPU is not at 100% utilization. WHere do I get multithreaded version of AviSynth, and do I need also all plugins in multithreaded version?

[SubJunk]

Ok let's move to high framerates. Do twice the framerate necessary mean doubled bitrate?
now I struggle with the speed. At Preset="slower" the encoding speed is really slow and I see CPU is not at 100% utilization. WHere do I get multithreaded version of AviSynth, and do I need also all plugins in multithreaded version?Twice the framerate means roughly 1.4x the bitrate for x264, but it depends on the type of video. for drama tv shows the bitrate will be almost the same but for action movies much higher

for avisynth mt i recommend first installing 2.6 (http://www.videohelp.com/tools/Avisynth) then copy this file (http://www.spirton.com/avisynth-2-6mt-with-version-info/) over the one in System32/SysWOW64

[Anakunda]

for avisynth mt i recommend first installing 2.6 (http://www.videohelp.com/tools/Avisynth) then copy this file (http://www.spirton.com/avisynth-2-6mt-with-version-info/) over the one in System32/SysWOW64

I fell like having problem setting QTGMC MT usage. Copied your avisynth.dll over old one into SysWOW64
This is my basic script playable:

LoadPlugin("D:\media\StaxRip\Applications\DGMPGDec\DGDecode.dll")
SetMTMode(5, 2)
MPEG2Source("H:\video\(pending)\Simpsons VIII (12) temp files\Simpsons VIII (12).d2v")
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
QTGMC( Preset="slow", EdiThreads=2 )
SelectEven()
Crop(6,0,-10,-0)

If I add the SetMTMode(2) command after MPEG2Source(), Staxrip crashes on preview, what's wrong?

/edit
SetMTMode(2) after MPEG2Source() doesnot invoke crash if I remove the first SetMTMode(..), does it matter?
Moreover StaxRip inhibits me from inserting anything before MPEG2Source on encode, how to elude this obstruction?

[SubJunk]

I'm not sure, I have never used StaxRip

[Didée]

Seeing the source is 'The Simpsons', it's questionable if using QTGMC is indicated at all. Simpsons might come along as telecined, or field blended (normconversion), or whatever. But it surely isn't "natural interlacing". Probably it's a case for either TFM(+TDecimate), or bob+Srestore. But not QTGMC.

[Anakunda]

Hello there, thanks for your support. This is finally the script that doesnot crash on my machine:

SetMTMode(5,1)
LoadPlugin("D:\media\StaxRip\Applications\DGMPGDec\DGDecode.dll")
MPEG2Source("test.d2v")
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
Crop(40,0,-40,-0)
SetMTMode(2)
QTGMC(Preset="Slow", EdiThreads=2)
#Distributor()

I have commented the Distributor() and it doesnot crash, is it better to leave it off if not crashing?
The only initial SetMTMode() values that do not crash are (5,1). The problem is that the utilization of both cores is still not 100%, though it seems to be higher than when running in ST mode. The problem is that if I increase the number of threads to SetMTMode(5,2), I get x264 crash.
Script invoked with command line
x264 --preset veryslow --tune film --crf 20 --sar 16:11 --output test.h264 script.avs
Please help.

Seeing the source is 'The Simpsons', it's questionable if using QTGMC is indicated at all. Simpsons might come along as telecined, or field blended (normconversion), or whatever. But it surely isn't "natural interlacing". Probably it's a case for either TFM(+TDecimate), or bob+Srestore. But not QTGMC.

This was a DVB-T stream so probably whatever it was originally, it is normal interlacing now, I see the stripes

[TheSkiller]

Yes, of course there is interlacing visible but that does not imply it is "natual interlacing" as Didée discribed it.
(Q)TGMC is working properly only with footage where every field represents a different step in time. With a Cartoon source this is pretty much never the case. With normconverted footage you don't have a fully natual type of motion anymore either (there is blending).
Sure, you can still use (Q)TGMC but there are more effective ways to deal with this type of footage.

[Anakunda]

Yes, of course there is interlacing visible but that does not imply it is "natual interlacing" as Didée discribed it.

Do you think about nonstandard interlacing causing these crashes? I can use different source then with natural interlacing, the goal is to find a working setup for QTGMC no matter what video source I use.
Thanks for notes for cartoon movies. Is TFM/TDecimate always better for animated sources?

[TheSkiller]

Do you think about nonstandard interlacing causing these crashes?
No, it certainly never depends on the "type" of interlacing or content of the picture whether or not a script crashes. Don't get me wrong, your interlacing is not "non-standard", it's just not the right type interlacing for (Q)TGMC.

The core technique that (Q)TGMC uses to deinterlace can produce bad results with sources where the motion is not natual, that's all.

the goal is to find a working setup for QTGMC no matter what video source I use.Forget it. There is no all-round script for every video source you could imagine. It starts with the issue we just pointed out with (Q)TGMC not being very suitable for cartoon stuff.
But of course it also depends a lot on your expectations, so in the end it's you who has to decide what's good.

TFM/TDecimate are THE tools to use for any telecined sources which includes non-CGI cartoons if it has not been normconverted somewhere in-between. In case of The Simpsons and if you're a PAL user you can be sure that it is normconverted if interlacing is visible. In that case only SRestore is an option (besides plain 50fps bob-deinterlacing or keeping it interlaced of course).

[atl]

Moving from 32bit to 64bit Avisynth version got increase from 48 to 61 FPS on i7-2600.
Using older MVtools
I still can't find MVtoos 2.5.11.2 or above compiled for 64bit, can somebody point me where can download it. Many thanks

[Mounir]

I have a problem with QTGMC i'm trying the "best settings" taken from the manual for instance this:
QTGMC( Preset="Slower", SourceMatch=3, Lossless=2, Sharpness=1.0, TR2=1 ) and it return an error there is no function VerticalCleaner not sure what this is about. My video is YUY2, huffyuv

[-Vit-]

I have a problem with QTGMC i'm trying the "best settings" taken from the manual for instance this:
QTGMC( Preset="Slower", SourceMatch=3, Lossless=2, Sharpness=1.0, TR2=1 ) and it return an error there is no function VerticalCleaner not sure what this is about. My video is YUY2, huffyuv
Those settings work fine for me on a YUY2 raw interlaced source. Have you got the VerticalCleaner plugin (http://home.arcor.de/kassandro/prerelease/VerticalCleaner.rar)...?

Must update the examples in the manual. There is, of course, no such thing as "best settings". However, this is fairly transparent, keeping the source relatively untouched:

QTGMC( "Slower", TR2=1, SourceMatch=2, Lossless=2, Sharpness=0.2, EZKeepGrain=0.6 )

Vary EZKeepGrain depending on source noise/grain (assuming you want to keep it - this is transparent remember). Adjust Sharpness if you feel it's necessary (faster motion videos generally need a bit more). Add and adjust NoisePreset if you wish (it defaults to "Fast") for some very slight improvements to fine detail/grain at the cost of some speed [very pedantic].

I don't really recommend SourceMatch=3 now, rarely makes any noticeable effect.

[Mounir]

You're right i didn't have this plugin, still i have an error window (not a script error) with AVSp the frames are not processed as i have to cancel this window all the time:

Traceback (most recent call last):
File "AvsP.pyo", line 5819, in OnMenuVideoToggle
File "AvsP.pyo", line 8925, in ShowVideoFrame
File "AvsP.pyo", line 9474, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0x3EF69000
Traceback (most recent call last):
File "AvsP.pyo", line 7123, in OnPaintVideoWindow
File "AvsP.pyo", line 9474, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0x3EF69000

etc...

[-Vit-]

I don't know what that is. Nothing QTGMC in there.

Could be out of memory I suppose, if you're running with many threads. If so cut down SetMTMode threads. And EdiThreads when using SourceMatch. Tweak the MemoryMax.
The usual multi-threaded juggle...

[Mounir]

This multithread thing is complicated i have followed the instruction, installed avisynth.dll in sys32, mt.dll in the plugin folder but no luck (i'm forced to close Avsp) plus i can't find infos on MemoryMax

my script so far:
Avisource("H:\MyVideo.avi", fourCC="HFYU", pixel_type="YUY2").trim(2500,2900)
MT(QTGMC( "Slower", EdiThreads=2, TR2=1, SourceMatch=2, Lossless=2, Sharpness=0.2, EZKeepGrain=0.6 ))

The maximum threads i can have is 2 on this cpu

Edit:
I have also tried (i found out for setmemorymax)

SetMemoryMax(512) #
SetMTMode(2,2) #
Avisource("H:\MyVideo.avi", fourCC="HFYU", pixel_type="YUY2").trim(2500,2900)
Setmtmode(2,2) #
AssumeTFF
QTGMC( "Slower", EdiThreads=2, TR2=1, SourceMatch=2, Lossless=2, Sharpness=0.2, EZKeepGrain=0.6 )
selecteven()
Distributor() # for multithreading

AvSp bug and i'm forced to close it, i think the problem is with masktools-v2.0a36 which i use for QTGMC

[Didée]

First script, corrected:

Avisource("H:\MyVideo.avi", fourCC="HFYU", pixel_type="YUY2").trim(2500,2900)
MT("""QTGMC( "Slower", EdiThreads=2, TR2=1, SourceMatch=2, Lossless=2, Sharpness=0.2, EZKeepGrain=0.6 )""", threads=2,overlap=16)
(When the filter call within MT(...) contains "quotes", then you need """triple quotes""" for the outer MT() call.)


Second script, corrected:

SetMemoryMax(512) #
SetMTMode(5,2) # Not using multithreading for the source filter is more safe
Avisource("H:\MyVideo.avi", fourCC="HFYU", pixel_type="YUY2").trim(2500,2900)
Setmtmode(2,2) #
AssumeTFF
QTGMC( "Slower", EdiThreads=2, TR2=1, SourceMatch=2, Lossless=2, Sharpness=0.2, EZKeepGrain=0.6 )
selecteven()
# Distributor() # don't use Distributor for apps using VfW API. (AvSP does, or not?)

With only 2 cores / 2 threads, the MT(""" ... """) script probably is faster for you.
(With complex scripts, the overhead for SetMTmode often eats a good part of the theoretical benefit when only 2 threads can be used. For QTGMC, SetMTmode starts to shine with 4 threads and above. With a quadcore, o'course. DualCore/2threads is too much a toy for this.)

[Boulder]

I think you could use SetMTMode(2) with HuffYUV since it's all keyframes.

[Didée]

Possible. But it doesn't help anyway - in comparison to calculating QTGMC's processing chain, decoding Huffy is totally peanuts.

Hence, better to avoid SetMTmode for the source filter completely. Best case=it doesn't help anything, worst case=it crashes. So, what to recommend to a user that is fighting with script crashing? :)

[Boulder]

Since dealing with SetMTMode can be compared to walking on the edge of a cliff, I usually have to try different things to get through a long encode. Changing SetMTMode for the source filter has helped sometimes, don't ask me why ;)

OT: I built a "new" second-hand computer last weekend. After a few crashes, I noticed that it's once again time to try to find the working MT-Avisynth version..grrrr.

[aegisofrime]

I have no idea why you guys say that SetMTMode is unstable. My script here:


SetMTMode(5,4)
DGDecode_mpeg2source("C:\Raws\Work.d2v",idct=5)
SetMTMode(2,4)
QTGMC(Preset="Slower")

Distributor()


Is perfectly stable. I use it for all my DVD encodes and it has never crashed before.

[-Vit-]

In the first post I've added a modded plugins package. All the key plugins have been recompiled using SEt's threading fixes and an extra tweak that prevents the main crash that I see when multi-threading. I can't guarantee they will help, but they might be worth a try. They won't prevent running out of memory if you use complex settings/many threads.

Read the instructions in the zip before asking what to do with the contents.

Instructions for stability and getting the best out of SetMemoryMax & SetMTMode are also in the first post (and the QTGMC instructions).
Also covers the EdiThreads setting, which is best set to 1 if you're getting problems.
Some people's computers simply don't like SetMTMode. Nothing to be done except fix AviSynth.

I don't recommend MT("") unless absolutely necessary, because splitting up the image will affect motion analysis (you always get problems at the edges with MVTools, with MT("") you have edges in the middle of your image...)

[Mounir]

Thanks Didée, MT work and setMtmode doesn't (error with mt_masktools-25.dll apparently) on this computer but i think i will avoid to use it as it split the image

[Mini-Me]

I went digging through the script to see how SourceMatch and the lossless modes interact with noise removal/retention modes. First, I want to congratulate -Vit- on writing the most beautifully commented script I've seen yet. :) Second, I want to ask if I properly understand the interaction of NoiseRestore and GrainRestore with Lossless mode 1.

In case it helps anyone (or helps -Vit- point out if I went wrong somewhere), here is the rough order of major QTGMC steps:
Obtain motion vectors: Bob, temporally smooth to fight bob shimmer, and perform motion analysis.
Optionally remove/bypass noise: Optionally denoise the original input clip and/or save extracted noise and fine detail (optionally stabilizing it) for later recovery. The [optionally] denoised clip is now known as the "inner" clip, and it is used in place of the original source clip for the rest of the filter (unless and until the extracted noise is readded).
Primary bob deinterlace: Perform a high-quality upscale/interpolation of the fields in the "inner" clip to attain full frame height. Temporally smooth the result with motion-compensated neighbors (using previous motion analysis) to fight bob shimmer, then repair to fight blurring (and artifacts from bad motion compensation?). (Side question: Is the temporal smooth also meant to absorb real detail and structure from motion-compensated neighbors, or does that get removed anyway by the repair step?)
SourceMatch: Optionally redo the previous step (I think) with input refined by the previous result, such that the new result will have original (non-generated) lines better matching the actual lines from the source. (Refine this up to two more times, though not exactly in the same manner). As far as I can tell, this is meant to recover detail lost in the previous temporal smoothing, and the degree to which the "original lines" match the original source also indicates how well the generated lines probably match the "original lines" of neighboring fields.
Lossless mode 2: If the lossless mode is 2, drop in the original fields of the inner clip here.
Resharpen: ...with a complicated series of steps involving limiting and back-blending.
GrainRestore: Optionally readd noise prior to the final smooth, proportional to GrainRestore.
Clean the result: Do a final [light, motion-compensated] temporal smooth, then repair. (Also, finish sharpness limiting if necessary.)
Lossless mode 1: If the lossless mode is 1, drop in the original fields of the inner clip.
NoiseRestore: Optionally readd noise after the final smooth, proportional to NoiseRestore.

What I've learned is that SourceMatch and Lossless mode 2 work perfectly and intuitively with denoising, NoiseRestore, and GrainRestore. The reason is, SourceMatch and Lossless actually match to the [optionally denoised] source rather than the original source. This makes perfect sense, and it's actually "easier" and more robust than I expected:
If you want to denoise, using the original fields (before denoising) for SourceMatch and Lossless would contradict that.
If you denoised with the intention of adding it back later, your intent was likely to retain the original noise "as-is." Matching to the inner clip with SourceMatch and Lossless accomplishes this, whereas using the true original fields and then adding noise back in would result in amplified noise.
If you didn't denoise at all, there's no difference between the original and inner clips anyway.

However, Lossless mode 1 does not seem to work well with GrainRestore > 0.0: Only the generated lines will have grain restored, and lossless mode 1 will subsequently replace the original lines with the [possibly denoised] lines from the inner clip.

That said, assuming GrainRestore is 0.0, Lossless mode 1 seems to work fine:
If you denoised the clip and NoiseRestore is 0.0, you'll end up with a denoised clip with lossless denoised lines from the original.
If you denoised the clip and NoiseRestore is 1.0, you'll end up with a noise-bypassed clip, and the original lines should presumably be the same as the ones from the source (because the exact difference between the source and the "inner" clip is being readded to the original lines...I think ;)).
If you didn't denoise the clip, you'll want to use 0.0 for NoiseRestore, but using higher values still produces the expected result of amplifying noise.
If you're using a Lossless mode of 1, you're probably looking for one of those results anyway.

Am I correct? If I'm wrong, let me know what I got wrong. If I'm right, it might be a good idea to add a few details to the instructions. The instructions say that Lossless mode 1 will use the exact original pixels from the source lines if NoiseRestore is 0.0, but isn't this only true if you did NOT denoise the clip? (If you did denoise the clip, then a NoiseRestore of 1.0 would actually give the original lines, correct?) Similarly, the directions mention nothing about how GrainRestore and Lossless mode 1 appear to interact poorly.

Thanks :)

[-Vit-]

Your description is correct in most every detail. Including the interaction between Lossless mode 1 and noise processing. Yes, I should note that GrainRestore (and by implication EZKeepGrain) are not effective with that mode. I do need to look more carefully at Lossless mode 1, the "true" lossless mode (I will also tweak these setting names for clarity). It hasn't been a recent priority since you can get very close to lossless with source-match and Lossless mode 2, without introducing the artefacts that true lossless mode 1 will bring.

I'm glad you spotted the detail behind the inner clip, especially the interaction of source match and noise processing. I don't think I explicitly note that. One other point to note is that resharpening occurs on the denoised clip, with the noise being added back on after sharpening. That means it won't enhance noise so much (but may miss some minor detail to be sharpened)...

Regarding your side question: Didee may have more to comment as this step inherits from original TGMC. The main temporal smooth (TR1) has a variety of effects depending on the quality of the motion analysis. It's main intent is to remove bob-shimmer. If the motion analysis is correct then it will slightly pull in detail from neighbor frames, but may also slightly weaken detail in the current. If the motion analysis is off, then it can blur or ghost or other nasty things - depends on the exact circumstances. The repair step helps to remove some of that.

The noise motion compensation step, designed to "stabilize" the noise, will also pull in detail from neighbor frames. It only looks at one neighbor frame, but I have a (very slow) variant that looks at several sucking in as much extra detail as possible from neighbors. Creates a kinda "enhancing" effect; not sure I like it. Can get the effect by setting EZKeepGrain high with a slow NoisePreset.

[Mounir]

I'm trying my script again right now with MT i'm not sure why VIt called the best settings "lossless" because it's not lossless for me , take a look:

Original:
http://img195.imageshack.us/img195/5138/originalrn.jpg
QTGMC:
http://img802.imageshack.us/img802/8199/qtgmc.jpg

settings used:
MT("""QTGMC( "Slower", EdiThreads=1, TR2=1, SourceMatch=2, Lossless=2, Sharpness=0.2, EZKeepGrain=0.6 )""", threads=2,overlap=16)

[-Vit-]

You're expecting too much. Horizontal detail like that is the Achilles heel of of all deinterlacers. You might find a different deinterlacer will do a better job for that particular shot, or maybe not, hard to tell from a single image.

[Mounir]

Well msu seems to get it right with their deinterlacer (http://www.compression.ru/video/deinterlacing/index_en.html), what you think ? I think it's neater maybe i'ts just me i don't know

[-Vit-]

I think it's neater maybe i'ts just me i don't know
They are different pictures to yours. No problem cases there. But if their deinterlacer works for you then use it.

[Mounir]

I wish i could but it's not free it appears. Anyways, i truly salute the efforts made for this deinterlacer and hope you make it even better.

[Didée]

Well msu seems to get it right with their deinterlacer (http://www.compression.ru/video/deinterlacing/index_en.html), what you think ? I think it's neater maybe i'ts just me i don't know

You believe the marketing fairytales? Those are cherry-picked spots to convince the audience.

If we were going to produce cherry-picked spots of QTGMC, they would look at least as impressive as those. :)

Also, you should post a small sample of your problem source. That screenshot is zoomed, and it's impossible to tell of what kind the source is at all. It could be a case of using QTGMC wrongly, or a case of filter-not-suited-for-the source (if it's telecined or fieldblending-interlaced).