QTGMC Deinterlacing Script (v3.32)

[-Vit-]

Originally Posted by Shon

-Vit- I needed a first option. Thank you!

You're welcome.

BTW, for the best quality noise use the NoiseDeint="Generate" option, for example:

QTGMC( Preset="Slower", NoiseBypass=2, NoiseRestore=0.4, NoiseDeint="Generate" )

This option improves how the noise itself is "deinterlaced". It's only a small improvement, but it might be helpful for you.

[-Vit-]

I've uploaded a new QTGMC version 2.51 in the first post

There are a number of changes:

• The default interpolator for almost all presets is now NNEDI3 rather than NNEDI2, so make sure you have it. This improves the quality and speed of most presets, provided you use version 0.9.2 or above of NNEDI3.
• To accommodate this change many presets have had their settings tweaked. Two presets are particularly different:
  • The "Super Fast" preset now uses NNEDI3 with the fastest possible settings rather than a Yadif variant as before. This improves quality considerably, but it's a tiny bit slower than before
  • The "Ultra Fast" preset also gives higher quality output. Before it wasn't using any repair mode, which created much motion blur. Now it uses tr2=3. However, this means a ~6% loss in speed. Set tr2=0 for the old faster behavior
• There's a new setting "EdiThreads", which allows you to specify how many threads EEDI3 and NNEDI2/3 will use. By default they will use one thread for each (logical) processor in your system. You may get better speeds on some scripts with more or less threads (experiment). Using less threads will also use less memory, which may help some complex/HD scripts, especially when also using MT or SetMTMode. Example:
  

  QTGMC( Preset="Very Slow", EdiThreads=6 )

• EdiMode can be set to "EEDI3+NNEDI3", which will use EEDI3 with its sclip parameter created with NNEDI3 - this should give a slightly improved EEDI3 result (but slower). This uses more memory - so be careful not to use too many threads if you're multithreading (EdiThreads or MT). E.g.
  

  QTGMC( Preset="Slower", EdiMode="EEDI3+NNEDI3" )

• Another new setting is "LosslessPreset". This is only used in lossless mode to drive the second lossless pass - it works exactly like the Preset setting except the default is "Fast". The quality difference between the lossless presets is minor so you can move towards faster settings here. Note: the LosslessEdi setting overrides the LosslessPreset edi mode setting.
  

  QTGMC( Preset="Very Slow", Lossless=1, LosslessPreset="Faster" )

• The output from ShowSettings has been made clearer and a minor bug fixed in that code
• Fixed a serious bug when using lossless modes on the higher speed presets
• I've tweaked the loading of Yadif again. The default behaviour hasn't changed - the calling script is required to load "Yadif" as normal if using settings that require it. However, now there is a global variable "YadifPath". It's initially empty, but if it is set to point to yadif.dll then it will be "autoloaded"

Thanks to Bi11 and henryho_hk for the suggestions that prompted some of these changes.

[dansrfe]

I love this function. Thanks for the update -Vit-. Brilliant script and of course kudos to Didée for coming up with TGMC in order for all this to happen!

[dansrfe]

Mediafire link to QTGMC v2.51: http://www.mediafire.com/?qxqp5q9dq2f5iqb

[-Vit-]

Originally Posted by dansrfe

Mediafire link to QTGMC v2.51: http://www.mediafire.com/?qxqp5q9dq2f5iqb

Thanks for the mirror, the link in the OP is now direct to the zip file attachment. I just put it on a filehost temporarily whilst waiting for the attachment to be approved.

[Boulotaur2024]

Great "wrapper" I've been using it on almost all my projects lately. It's funny because the last changes you brought correspond more or less to what I was doing manually by using the ad-hoc parameters. I still think that maybe the default sharpening settings are a bit high but that may be just me since I usually resize x2 the QTGMC ouput which needs not to be "too sharp".

Thank you again for this function, very well documented too.

[dansrfe]

How can I use QTGMC to bob & interpolate at decent speeds on an i7 using 2.6 MT?

[-Vit-]

Originally Posted by dansrfe

How can I use QTGMC to bob & interpolate at decent speeds on an i7 using 2.6 MT?

Use a script like this:

SetMTMode(5,8) # 8 threads for this script (the default for most i7s)
# Insert your source command here
SetMTMode(2)
QTGMC( Preset="Slow", EdiThreads=8 ) # 8 threads for NNEDI3 (the default for most i7s)
Distributor()

Change the QTGMC preset as necessary. Also tweak your encoder for the speed you require (e.g. x264 preset).

You can try increasing / decreasing the two threads values for best speed. I find having slightly fewer EdiThreads is best for my machine.

If it's a HD source then you can easily run out of memory with so many threads on a 32-bit system. So go 64-bit (I believe all the appropriate plugins exist now), or reduce the threads considerably and use a SetMemoryMax(xxx) at the start (experiment for best xxx value). Also encode in multiple passes, 1st pass QTGMC to lossless, 2nd pass lossless to x264 or whatever. MeGui pre-render job does exactly that. Will need lots of disk space for the lossless step. QTGMC is very forgiving with HD and you can get away with the quickest presets if you wish.

OC that i7 if you haven't already

[dansrfe]

Is encoding to lagarith and then sending that to x264 going to work the same way as well?

[-Vit-]

Originally Posted by dansrfe

Is encoding to lagarith and then sending that to x264 going to work the same way as well?

I haven't used lagarith, but it's the same principle. Isn't encoding to huffyuv faster though? I know huffyuv will create larger files, but if you're going to encode to x264 afterwards then it doesn't really matter does it?

[dansrfe]

That's true^. btw what purpose does the "lossless" variable have? Since I'm encoding to a lossless format, be it megui pre-render, lagarith, or even huffyuv what does QTGMC's lossless do?

[-Vit-]

Originally Posted by dansrfe

That's true^. btw what purpose does the "lossless" variable have? Since I'm encoding to a lossless format, be it megui pre-render, lagarith, or even huffyuv what does QTGMC's lossless do?

Yeah, I suppose I didn't explain it clearly anywhere. I'll add this info to the OP:

(Q)TGMC separates the interlaced source fields, then "fills in" the missing lines (with the help of an interpolator) to create a shimmer-free progressive output. However, by default, the original field lines do not remain unchanged in the output. Put simply, the input pixels are not in the output. This is not ideal - we are not rescaling, just filling in the "missing" lines so it would seem best to keep the original fields unchanged. But that is hard to do whilst removing the shimmer from the interlacing.

QTGMC's lossless mode will do additional processing to keep the original fields exactly as they were whilst still retaining as shimmer-free an output as possible. This mode gives output that is truer to the source, but it can contain some minor combing or bob-shimmer. It also retains any noise from the source (QTGMC denoises somewhat by default)

This mode has nothing to do with lossless encoding.

BTW. Megui pre-renders are encoded to huffyuv

[dansrfe]

Ok That makes things clearer. Thanks!

[yup]

dansrfe!
Try other lossless codec for example Ut. On my Core2 QUAD work faster. Lagarith use only 2 threads. I use Lagarith only for archive purpose, for intermediate using Ut.
yup.

[jpsdr]

@dansrfe
I also strongly suggest you tu use UT Video codec. I've made some tests, and confirmed they work faster. Problem of huffyuv is that you've not YV12 support, thing you have with UT Video. File with UT Video (YV12 codec) are a little bigger than lagarith, even in best compression, but it's realy a little, less than 10%.

[dansrfe]

Can you guys direct me to the link for UT Video?

[jpsdr]

Google : UT Video

[Revgen]

huffyuv does have yv12 support if you use the ffdshow version. I use it all the time to capture HDTV.

[moozooh]

Much thanks for taking over for Didee and his awesome script!

I have a question. I'm processing a considerably clean (very little noise, mostly MPEG2 artifacts if any) 60i game video for further encoding to x264 at around the crf of 22..27. Will it make sense for me to retain/generate the noise when using the slowest QTGMC presets? It seems like it would only complicate encoding since at that crf x264 will smear the noise invariably whilst spending more bits than otherwise in an attempt to preserve it.

Thanks in advance.

(Vit, out of curiosity… are you Russian?)

[-Vit-]

Originally Posted by moozooh

I have a question. I'm processing a considerably clean (very little noise, mostly MPEG2 artifacts if any) 60i game video for further encoding to x264 at around the crf of 22..27. Will it make sense for me to retain/generate the noise when using the slowest QTGMC presets? It seems like it would only complicate encoding since at that crf x264 will smear the noise invariably whilst spending more bits than otherwise in an attempt to preserve it.

The two slowest presets, "Very Slow" and "Placebo" use the wider temporal radii in the TGMC algorithm. This denoises strongly creating a very clean, but rather artificial look, also losing some detail. To counteract this, those presets also use some noise bypass to retain some of the detail/grain that would otherwise be lost. Obviously you can do this manually in the other settings if there's some grain you particularly want to keep.

Depending on the game content, there may well be grain in the textures/backgrounds (rather than over the entire image) that might be lost at the highest settings. And, assuming that this is a 720p+ capture, then a CRF of 22 might be enough to have caught some of it. But it will be a lesser effect than on the naturalistic sources for which the presets were designed. So, yes it may well be OK to reduce this processing to save on time & filesize (and memory used during the encode - important if you intend to multithread).

However, this is just speculation - I have only worked with a little game footage on the default "Slower" setting - and I didn't try noise bypass. Others will have more experience than I do for that kind of source. Why not just try encoding a few thousand frames each way and compare?

Originally Posted by moozooh

(Vit, out of curiosity… are you Russian?)