QTGMC Deinterlacing Script (v3.32)

[-Vit-]

I'll give that a go. Which version should I go for?
I would suggest SEt's 2.6MT (http://forum.doom9.org/showthread.php?t=148782) as SEt has recently updated it with a multithreading fix. It has been reported as more stable, certainly works fine for me. If you get stability problems try the other versions.

[SubJunk]

Wow, I hadn't noticed he updated it. I never thought I would see the day *tear*

[Undead Sega]

I would suggest SEt's 2.6MT (http://forum.doom9.org/showthread.php?t=148782) as SEt has recently updated it with a multithreading fix. It has been reported as more stable, certainly works fine for me. If you get stability problems try the other versions.

Oh okay then, so is his download links all Avisynth MT?

Should I also upgrade my current Avisynth to 2.6 from 2.5.8?

[-Vit-]

Get only the latest dated version. You are effectively upgrading by copying SEt's avisynth.dll.

[Undead Sega]

So I would upgrade my current Avisynth by just copying SEt's avisynth.dll? Which is at the same time an MT version? :D

[-Vit-]

You learn quickly

[Undead Sega]

Excellent.

Would I probably see a huge difference in speed? especially in regards to the hardware/specs I have of my PC?

[Br4twurscht]

Hi,

I have problem with a video. I hadn't interlaced source not very often yet.

I'm not sure how I can deinterlace the following source:
edit: entfernt

It's a clip of the docu How the Universe Works (http://en.wikipedia.org/wiki/How_the_Universe_Works). I'm from germany so my version is in german ("Das Universum - Eine Reise durch Raum und Zeit").

But thats everything I can safely say about this clip. MediaInfo says it is 25 fps, but I think its 50 fps. I tried both (assumefps).
I use StaxRip with ffVideoSource. If i look then at the raw video-stream i can see that the frames are jumping.
I tried to solve the problem with ivtc, so (if I merge all avisynth-plugin entries) this is my script:

FFVideoSource("%source_file%", cachefile="%working_dir%%source_name%.ffindex")
AssumeFPS(50.000)
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
AssumeTFF()
Telecide(guide=2, post=0)
Decimate(cycle=2)
QTGMC( Preset="Fast" )
SelectEven()
Crop(%crop_left%,%crop_top%,-%crop_right%,-%crop_bottom%)
LanczosResize(%target_width%,%target_height%)

The problem is, that the result is not smooth and it seems that there are some standing frames (maybe blending???).
Another strange thing is, that MediaInfo says it would be NTSC. NTSC with 25fps??? Maybe a standard conversion of a stupid encoding guy?!?

Till now I helped myself with using DirectShowSource. So the Source is reading with ffdshow. Then the frames are right and i can deinterlace it simply with QTGMC.
But i think the quality would be better if would use ffvideosource. Is it right? And how i can solve my problem?

regards
Br4twurscht

[Didée]

It's a fieldblended normconversion. HDTV/BluRay does not safe you from crappy sources. (And noone has been 'stupid, it's the "standard" result when a conversion box changes from NTSC to PAL.) Your script is bad anyway - first TIVTC then bob-deinterlacing does not make sense. ;)

Look out for the "Srestore" script, then use sth like

bob(0,0.5) # or yadi, or tdeint, ...
SRestore()

or

QTGMC(preset="fast")
Srestore(dclip=bob())

[Br4twurscht]

Thank you, I will try it soon :)

[Undead Sega]

Okey dokey, I have copied over the dll thus replacing the original, now I was reading on the MT usage of this script but I couldnt quite work out how to use SetMemoryMax and SetMTMode, like what parameters to put in. So, if I have a Q9550 (4 Core) processor and 8GB of DDR2-800 Ram, how will I make use of that exactly?

[Groucho2004]

Okey dokey, I have copied over the dll thus replacing the original, now I was reading on the MT usage of this script but I couldnt quite work out how to use SetMemoryMax and SetMTMode, like what parameters to put in. So, if I have a Q9550 (4 Core) processor and 8GB of DDR2-800 Ram, how will I make use of that exactly?

A simple search for these terms ("SetMemoryMax" "SetMTMode") would result in a huge number of posts where other users report their experiences with Avisynth MT and its usage. There are also instructions in the very first post of the thread you are reading right now.

After 4 years and more than 650 posts one would think that you figured out how things work here. I can only assume that you're too lazy to search and prefer things to be spoon-fed to you.

[johnmeyer]

... I couldn't quite work out how to use SetMemoryMax and SetMTMode, like what parameters to put in. So, if I have a Q9550 (4 Core) processor and 8GB of DDR2-800 Ram, how will I make use of that exactly?As already mentioned your question is easily answered by reading the SetMTMode section of the documentation. That documentation gives very good instructions on how to "tune" the multi-threading settings for your situation.

I found that the version of AVISynth used makes a BIG difference in the stability of multi-threading with QTGMC. Also, you need to make sure you get the correct versions of all the plugins. Finally, if you are serving the results into something else -- in my case, this is often MeGUI -- then you may find that you have to adjust downwards the number of threads allocated to AVISynth multithreading. Here is the relevant MT section of a script I often use when using QTGMC and then opening the AVS file with MeGUI (I have a four-core/eight thread i7 computer):

SetMTMode(5,4)
AVISource("e:\frameserver.avi")
SetMTMode(2)

[Xaurus]

Hello, is there a guide or tutorial somewhere how to use this with media player classic home cinema?

[SubJunk]

It would be too slow. This isn't for realtime processing.

[-Vit-]

It can be done if you have a reasonably recent machine. QTGMC isn't designed for realtime viewing, but the faster presets will go realtime easily on SD material with multithreading.

Regarding MPC-HC, I can't get recent builds to work with avisynth scripts, though that might be a problem at my end - I haven't looked at the issue much. The old 1.3.1249.0 version works fine for me. Just drag'n'drop an avs file in there and it plays. So to answer the question directly: learn to write basic avisynth scripts, then make a multithreaded QTGMC script as described in the first post of this thread, drag it into MPC-HC (maybe an older build). Start with preset "Super Fast" and see if your machine can handle it...

[aegisofrime]

It would be too slow. This isn't for realtime processing.

It can be done if you have a reasonably recent machine. QTGMC isn't designed for realtime viewing, but the faster presets will go realtime easily on SD material with multithreading.

Regarding MPC-HC, I can't get recent builds to work with avisynth scripts, though that might be a problem at my end - I haven't looked at the issue much. The old 1.3.1249.0 version works fine for me. Just drag'n'drop an avs file in there and it plays. So to answer the question directly: learn to write basic avisynth scripts, then make a multithreaded QTGMC script as described in the first post of this thread, drag it into MPC-HC (maybe an older build). Start with preset "Super Fast" and see if your machine can handle it...

On my undervolted, stock clock i7-2600K preset Fast runs perfectly fine on DVD content. So I won't make a sweeping statement like that SubJunk. It depends on the content, your PC specs and preset used, like -Vit- said.

-Vit-, drag and dropping the .avs file works on my end. Build 1.5.2.3329 supplied as part of K-Lite Mega Codec Pack.

[Xaurus]

Well, I would assume a 6-core 4.0 Ghz. Intel 980x would suffice?

In any case, I have some issues with proper deinterlacing some 1080i videos.

I thought that this might do the trick, but it's so complex that
I'll skip it. I tried the YADIF implementation in FFDSHOW but
that gave me other problems, like dropped frames etc.

Thanks anyway. :thanks:

[SubJunk]

I sit corrected :)

[Undead Sega]

A simple search for these terms ("SetMemoryMax" "SetMTMode") would result in a huge number of posts where other users report their experiences with Avisynth MT and its usage. There are also instructions in the very first post of the thread you are reading right now.

After 4 years and more than 650 posts one would think that you figured out how things work here. I can only assume that you're too lazy to search and prefer things to be spoon-fed to you.

Oh no, absolutely not 'lazy' at all, I have done stuff that I've figured out myself but its just sometimes I have a hard time reading and understanding what is being said, thus not very clear to me which is why I just had to ask here, and that I dont know how some of the parameters I would have to enter corrospond to my system or if I'm doing it right :(

As already mentioned your question is easily answered by reading the SetMTMode section of the documentation. That documentation gives very good instructions on how to "tune" the multi-threading settings for your situation.

I found that the version of AVISynth used makes a BIG difference in the stability of multi-threading with QTGMC. Also, you need to make sure you get the correct versions of all the plugins. Finally, if you are serving the results into something else -- in my case, this is often MeGUI -- then you may find that you have to adjust downwards the number of threads allocated to AVISynth multithreading. Here is the relevant MT section of a script I often use when using QTGMC and then opening the AVS file with MeGUI (I have a four-core/eight thread i7 computer):

SetMTMode(5,4)
AVISource("e:\frameserver.avi")
SetMTMode(2)

I see, well at the moment I'#m just taking stuff to VirtualDub and save them as a lossless avi which then I take into MeGUI, I find that its more convenient for me this way. Before seeing your post, I was using:

SetMemoryMax(800)
SetMTmode(5,4)
mpeg2Source("D:\xxx.d2v")
AssumeTFF()
QTGMC(Preset="Placebo", TR2=3, EdiMode="NNEDI3", ChromaEdi="NNEDI3", NNeurons=4, EdiQual=2)

...on a SD source, but I found (speed-wise) it hasnt really improved at all :( Maybe I'm doing something wrong here?

[Boulder]

You don't have the SetMTMode(2) call after the MPEG2Source line so it's single threaded (except for the internal multithreading that QTGMC uses for NNEDI3).

[Undead Sega]

Alrighty, I gave it a quick shot and it seems alittle faster when previewing it, now I'm doing the encoding and seems alittle faster as well, what does SetMTMode(2) do exactly? Can this (and my SetMTMode() script) be applied to other filters as well?

[johnmeyer]

Before seeing your post, I was using:

SetMemoryMax(800)
SetMTmode(5,4)
mpeg2Source("D:\xxx.d2v")
AssumeTFF()
QTGMC(Preset="Placebo", TR2=3, EdiMode="NNEDI3", ChromaEdi="NNEDI3", NNeurons=4, EdiQual=2)

...on a SD source, but I found (speed-wise) it hasnt really improved at all :( Maybe I'm doing something wrong here?Where's the second SetMTMode? Have you read the documentation?

Multithreading functions (http://avisynth.org/mediawiki/Internal_functions/Multithreading_functions)

[Didée]

SetMemoryMax(800)
SetMTmode(5,4)
mpeg2Source("D:\xxx.d2v")
AssumeTFF()
SetMTmode(2)
QTGMC(Preset="Placebo", TR2=3, EdiMode="NNEDI3", ChromaEdi="NNEDI3", NNeurons=4, EdiQual=2)
Like so.

(However, to get into the swing of things, I wouldn't use 'placebo' of all presets ...)

[aegisofrime]

SetMemoryMax(800)
SetMTmode(5,4)
mpeg2Source("D:\xxx.d2v")
AssumeTFF()
SetMTmode(2)
QTGMC(Preset="Placebo", TR2=3, EdiMode="NNEDI3", ChromaEdi="NNEDI3", NNeurons=4, EdiQual=2)
Like so.

(However, to get into the swing of things, I wouldn't use 'placebo' of all presets ...)

Why not?

[-Vit-]

On speed: Placebo settings are less effective multi-threaded. Often with more extreme scripts you get <100% CPU usage, which affects processing speed more than expected. Some kind of bottleneck in the processing. Presets "Slower" and "Slow" are very well tuned for multi-threading and give great results.
____

On placebo: I would like to tweak the Placebo and Very Slow settings. They're perfectly usable (not as placebo as they could be really), but some of the choices are... particular, suiting some sources more than others. Most notably those presets set TR2 > 1, whereas that setting should better be tweaked on a per-source basis. So if you must use "Very Slow" or "Placebo" I suggest you at least tweak TR2 to taste.

I have considered adding source-match settings to "Very Slow" & "Placebo", since they create a result measurably more accurate to the source. However, the original rationale for TGMC was to aim for stability and compressibility (i.e no bob-shimmer & temporally smoothed), not absolute accuracy. Source-match doesn't introduce shimmer but it does recover more source detail including any noise/artefacts present. This affects compressibility, and in the case of a lower quality source recovering source artefacts might not be considered an improvement. Also default (Q)TGMC enhances/sharpens the image in its effort to counteract the temporal smoothing. It can overdo this in some circumstances leading to a slightly sharper/enhanced output. Source match will not oversharpen and is truer to the source sharpness, but regardless of accuracy, less sharpness might not be considered an improvement.

So there is a fundamental question about what constitutes an "improvement" in settings, and consequently what should be used for Placebo. Some things are obvious, such as wider, more precise searches for nnedi & MVTools, but these make less of a difference. Other settings that undoubtedly improve accuracy, such as noise-bypass and source-match, may not actually suit people's personal taste / expectations...

I'm of the opinion that the so-called "best" settings should strive for absolute transparency - a shimmer-free, combing-free deinterlace that is otherwise as exact to the source as possible. The nearest you can get to the theoretical progressive source. But that's not what people are used to from (Q)TGMC, they expect smoothing and enhancement too.

[Boulder]

Maybe you should create two basic scenarios, one for the original purpose of TGMC and the other for the enhanced accuracy. Then both of them could have their own presets, and presets make the function much easier to use (due to the huge amount of parameters to adjust).

[aegisofrime]

So in other words, its not for quality reasons that Didee says not to use Placebo, but rather they don't multi-thread effectively?

[Mini-Me]

Maybe you should create two basic scenarios, one for the original purpose of TGMC and the other for the enhanced accuracy. Then both of them could have their own presets, and presets make the function much easier to use (due to the huge amount of parameters to adjust).

Going with what Boulder said, you could borrow x264's tune system: Create different tunings (e.g. "transparency" vs. "enhancement") that modify the settings. Your tuning system would probably be a lot more complex than x264's, since the tuning value would change different things based on the preset...but it's an option. I'm not sure how many more parameters QTGMC can take before causing cosmic rifts though. ;)

So in other words, its not for quality reasons that Didee says not to use Placebo, but rather they don't multi-thread effectively?

The "problem" with placebo is not quality-related; the output is beautiful, especially with SourceMatch, etc. However, the output of most other presets is pretty beautiful too. Placebo is extremely slow (and not just because of multithreading effectiveness), and you might be surprised at how good the faster presets look. Even the super fast preset produces far better results than most deinterlacers. I think Didee was just suggesting that you try a faster preset while you're first testing out QTGMC, and then you can compare settings and see if placebo is really worth the time investment for you.

[aegisofrime]

The "problem" with placebo is not quality-related; the output is beautiful, especially with SourceMatch, etc. However, it's extremely slow, and you might be surprised at how good the faster presets look. I think Didee was just suggesting that you try a faster preset while you're first testing out QTGMC, and then you can compare settings and see if placebo is really worth the time investment for you.

I have been using QTGMC and it's predecessor TGMC for about two years now. I agree that the slower presets don't really bring about a huge improvement in quality. It's a case of diminishing returns I guess. However, for some important videos that I like I tend to just "to hell with it" and go Placebo. My thinking is that might as well do it once and do it good. Other than that, yes Slower does a great job most of the time. I was wondering from Didee's somewhat cryptic comment if he had found a bug with Placebo or something. :p

[Mini-Me]

I have been using QTGMC and it's predecessor TGMC for about two years now. I agree that the slower presets don't really bring about a huge improvement in quality. It's a case of diminishing returns I guess. However, for some important videos that I like I tend to just "to hell with it" and go Placebo. My thinking is that might as well do it once and do it good. Other than that, yes Slower does a great job most of the time. I was wondering from Didee's somewhat cryptic comment if he had found a bug with Placebo or something. :p

Ah, my bad. I should have read more closely. :o I'm the same way with important videos, too...sometimes, I feel I'd regret giving them anything less than the best.

[-Vit-]

I always assumed that a Placebo preset was so-named because it uses maximal settings that make you feel better but don't really doing anything much more than normal settings. It's supposed to be an exemplar of the law of diminishing returns. I suspect Didée was merely suggesting to start at a more standard setting since it would almost certainly be good enough. Although it's possible he intended to critique specific settings choices, as I did above.

Actually, sometimes there is very good reason to use settings beyond the defaults: when you have a low resolution but high quality source, which you expect to upscale considerably. For example, a DVD that has been letter-boxed to 16:9, giving an effective source resolution of 720x360 say. If you upscale that to a big screen, you're going to see the pixels in even more detail than usual. Source match and/or other slower settings are more readily visible and justifiable in this situation. My experience is that [given good source quality] resolution is the most important factor for selecting appropriate preset/settings for QTGMC (and some encoding settings too). Which works the other way of course, for HD material the default "Slower" is overkill. The current development version (yes, I am working on it, just very, very slowly...) uses the input resolution to determine some internal settings. But I am also very tempted to set a faster default preset for higher resolution sources...

And yes, the slower presets/settings create improvements that the ordinary viewer just won't notice. Yet I think such settings are important for script/plugin development: a single improvement of say 1% quality is negligible, but accumulate a sequence of such improvements and we get real progression over the long term. However, for day-to-day usage there's little practical purpose in squeezing the final 1% quality out of today's scripts if it means doubling your processing time. Instead keep the original, and re-encode in a couple of years when the scripts are [might be] 10% better.

[kolak]

It's very true about resolution. I have many good quality sources (sometimes also very bad) and when you upscale PAL to HD you can see big difference if deinterlacing was done properly. When you start with HD source there's almost no difference. It would matter if you would upscale to 4K, but when going down it almost makes no difference (which makes perfect sense).

I had to upscale some PAL interviews recently- just quite good, uncompressed source. I've noticed that there is difference even between medium and slow preset (in the same time YADIF looked way worse). To make it more interesting our Kuro plasma does (for my eyes) even better job. All Pioneer plasmas have very good processing.

I'm still struggling to get decent speed with QTGMC thought :(


Andrew

[Mini-Me]

With my 480i sources, I can flip between interleaved clips and see an immense increase in vertical detail with slower presets, SourceMatch, etc. Between the slowest presets and "super fast", the difference in detail looks similar to a 2x vertical resolution increase (and even "super fast" totally slaughters deinterlacers like Yadif in overall quality). It's definitely there, and the more I magnify the image, the more I see the difference. I can only imagine the difference with a projection setup.

My ideal settings so far are (preset = "placebo", SourceMatch = 3, MatchPreset = "placebo", MatchPreset2 = "placebo", lossless = 1, NoiseProcess = 1, NoisePreset = "slower", DenoiseMC = True, NoiseDeint = "Generate", StabilizeNoise = False, GrainRestore = 0.0, NoiseRestore = 1.0). StabilizeNoise = True looks even better, but that breaks losslessness. ;) Those settings aren't exactly feasible for my setup today, but as you say, that's why keeping the originals is so important...I can still get excellent results today with faster presets and then upgrade the processing when I have a couple orders of magnitude more horsepower. ;)

[zerowalker]

i have tried finding it myself with no success, so i will try to ask here;D
is there a way for QTGMC to work on 64 bit (without failing of course), with mt and etc, for good speed?
if so, can you help me get it to work, i have found every plugin except NNEDI3 (which i found, but it doesn´t work i think), maybe that isn´t the problem, but still.

PS: Can you please tell me wich Avisynth i should use also, as there are so many versions:)

[aegisofrime]

i have tried finding it myself with no success, so i will try to ask here;D
is there a way for QTGMC to work on 64 bit (without failing of course), with mt and etc, for good speed?
if so, can you help me get it to work, i have found every plugin except NNEDI3 (which i found, but it doesn´t work i think), maybe that isn´t the problem, but still.

PS: Can you please tell me wich Avisynth i should use also, as there are so many versions:)

You need to use NNEDI3 0.9.2, as for 0.9.4 there isn't a 64-bit build yet. Although I hope there will be, since 0.9.4 seems to bring about enough performance improvements to make QTGMC 32-bit almost as fast as 64-bit (although still less stable than 64-bit)

Link here: http://bengal.missouri.edu/~kes25c/nnedi3_64.dll

[zerowalker]

what tool do you use for AVS to AVI?;O
Thanks for the link:D!

EDIT: What settings in the script will make it more stable?
i want to use placebo, and it´s a very long video, 4 hours, maybe you can set it to clip video every 1 hour or something;D?

EDIT 2: Got Quad core btw, 8gb ram

[SubPixie]

I recently discovered the motion blur capabilities of QTGMC and thought the output was amazing calling the script this way :

QTGMC( Preset="faster", FPSDivisor=2, ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=360, SBlurLimit=8 )

The problem is that by doing so it runs through all the QTGMC processing and modifies sharpness (amongst other things I guess....) where I'm only interested in the motion blur part. In fact I'd need a standalone motion blur script out of QTGMC :D

Maybe I could do that more easily by running a simpler MFlowBlur script ? (But I really like the output of QTGMC)

[-Vit-]

All QTGMC processing is optional including the deinterlacing. To get a standalone motion blur do this:

QTGMC( "Faster", ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=360, SBlurLimit=8, \
InputType=1, TR0=0, TR1=0, TR2=0, Rep0=0, Rep2=0, SMode=0, SLMode=0, Sbb=0, NoiseProcess=0 )


In this case the preset simply selects the accuracy of the motion analysis. The end part of the line sets progressive input and switches of all the deinterlacing processes.
Despite QTGMC being a huge script there's no extra processing overhead to this except the initial parsing (a fraction of a second I guess). All unused processes are entirely bypassed, not even initialized.

However, you say you really like the output of QTGMC, which suggests you actually want some kind of temporal processing. So maybe you want the progressive repair mode combined with motion blur:
QTGMC( "Faster", InputType=1, Sharpness=0.4, ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=360, SBlurLimit=8 ) # Tweak sharpness to taste
This will remove any shimmer residue, temporally denoise a little and enhance a little depending on sharpness.

[kolak]

Vit, what cmd should I use for deinterlacing only. I don't want any processing, just deinterlace, so the file is as close as possible to the source (but deinterlaced :))


Thanks,
Andrew

[Boulder]

You might want to try the settings -Vit- mentions in this answer to my question: http://forum.doom9.org/showthread.php?p=1488143#post1488143

[Didée]

Vit, what cmd should I use for deinterlacing only. I don't want any processing, just deinterlace, so the file is as close as possible to the source (but deinterlaced :))

Sorry I'm not Vit, but that is easy to answer. If you want *strictly* only-deinterlacing, with *strictly* no additional processing, here you go:

NNEDI3(field=-2)


*All* code of TGMC/QTGMC is about "additional processing to improve the result of a given basic deinterlacer". Without any additional processing, you're left back with your raw basal deinterlacer of choice.

And no, there isn't really anything like a "bare minimum" of processing. Or perhaps like this: the bare minimum you wouldn't accept quality-wise.

[kolak]

I'm happy with any answer, which is informative:)

How does NNEDI3 compare to YADIF?
I've tried YADIF, but it's no near QTGMC.

Other way- what is the cmd line for good deinterlacing and keeping all noise/grain.
Sometimes QTGMC output looks digital- has some "special" look.

Thanks,
Andrew

[kolak]

You might want to try the settings -Vit- mentions in this answer to my question: http://forum.doom9.org/showthread.php?p=1488143#post1488143

Tanks.

Sounds good- bit different than I expected :) EZKeepgrain=1 -I thought this keeps all grain :)


Andrew

[aegisofrime]

Vit, what cmd should I use for deinterlacing only. I don't want any processing, just deinterlace, so the file is as close as possible to the source (but deinterlaced :))


Thanks,
Andrew

If you have read the documentation, that is what SourceMatch claims to try to do, hence the name. I would give that a shot if I were you.

Although personally I like the denoised sharpened look that non-SourceMatch gives :p

[kolak]

I went through readme, but it's not that clear- quite few settings, which work together (or not) to achieve some result.

Andrew

[-Vit-]

My personal favorite settings remain the same as Boulder's reference above, slight variations on this:
QTGMC( "Slower", SourceMatch=2, Lossless=2, EZKeepGrain=0.5, Sharpness=0.3 )
Vary EZKeepGrain depending on the noise/grain in the source and how much you want to keep it (warning: subtle effect) and adjust sharpness to taste (from around 0.05 to about 0.5).
This gives a result accurate to the source including source grain/noise/artefacts (so it can be rough if your source is not high quality). It won't shimmer like NNEDI3 or Yadif. It reduces that "digitally enhanced" look of the defaults.

[SubPixie]

All QTGMC processing is optional including the deinterlacing. To get a standalone motion blur do this:

QTGMC( "Faster", ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=360, SBlurLimit=8, \
InputType=1, TR0=0, TR1=0, TR2=0, Rep0=0, Rep2=0, SMode=0, SLMode=0, Sbb=0, NoiseProcess=0 )


In this case the preset simply selects the accuracy of the motion analysis. The end part of the line sets progressive input and switches of all the deinterlacing processes.
Despite QTGMC being a huge script there's no extra processing overhead to this except the initial parsing (a fraction of a second I guess). All unused processes are entirely bypassed, not even initialized.Thanks for you answer Vit, that's exactly what I needed. By the way, do you know if there's a reason to set the preset to anything higher than "Faster" in order to get... better quality motion blur ? (I don't think so but just asking for the sake of completeness)

Oh and thanks for all of your work you and Didée, this is... simply amazing quality-wise.

[-Vit-]

By the way, do you know if there's a reason to set the preset to anything higher than "Faster" in order to get... better quality motion blur ?Only difference is accuracy of motion analysis, but as you're blurring that's of rather less importance than in the normal case. Slower presets might occasionally find the correct motion when the faster ones miss it (which would make the blur go the wrong way or look odd). Depends on the speed/complexity of motion in your source.
Slower presets may slightly increase sharpness of slow moving areas (although SBlurLimit helps more there) and they may also slightly help the blur "bleeding" reduction of the higher SBlurLimit values. Both of those effects relatively minor.

[SubPixie]

You're right I did notice bad motion analysis (artefacts) using the "Faster" preset (bad scene change detection, you know, with objects abruptly and unnaturally zooming in...). But I noticed I have more or less the same problem with Interframe no matter what quality preset I use, so I guess the culprit here is MVTools... (?)