QTGMC Deinterlacing Script (v3.32)

[Stormborec]

Is this setting really the most closer to the original interlaced source, or did I something wrong understand?

QTGMC( Preset="Very Slow", EZKeepGrain=0.5, SourceMatch=2, Lossless=2, Sharpness=0.1, Sbb=0 )

[cybersharky]

I'm using the SEt's latest avisynth MT 2.6.0.3 and -Vit-'s plugin's from: http://forum.doom9.org/showpost.php?...postcount=1126

LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("B:\Gary\voy\VideoFile.d2v", info=3)

LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\AddGrainC.dll")
LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\RemoveGrainSSE2.dll")
LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\RepairSSE2.dll")
LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\mt_masktools-26.dll")
LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\mvtools2.dll")
LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\SSE2Tools.dll")
LoadPlugin("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\nnedi3.dll")
Import("B:\Gary\MeGUI_2308_x86\tools\avisynth_plugin\QTGMC-3.32.avsi")

QTGMC( Preset="Slow" )

Edit changed all the plugins, now I get:

[LigH]

Therefore the "latest" version is a patch for mt_masktools26.dll by 06_taro for AviSynth MT 2.60 alpha 4, not 3.

[cybersharky]

None of those included in -Vit-'s 2.6 package work with 2.6.0.3.

[Reel.Deel]

Originally Posted by cybersharky

None of those included in -Vit-'s 2.6 package work with 2.6.0.3.

In my case that's partially incorrect. All of -Vit-'s 2.6 plugins seems to work with SEt's 2.6.03 MT 2012.05.16.
With newer builds I get access violations and similar errors like what you have posted above. That's the main reason why I stick to the older build.
I wonder what change made those plugins incompatible?

[LigH]

A programmers' interface to set the frame caching strategy by another plugin, if I understood the brief explanation by 06_taro well; I did not read the diff, but it should be included.

[cybersharky]

What I've done so far: http://forum.doom9.org/showthread.php?t=167671

Posting here because I was going to use QTGMC, but the source is only partially interlaced. What would happen to the progressive frames if I used QTGMC?

Or is there a way to conditionally use QTGMC based on frame type?

[osgZach]

If you consider manually writing out a bunch of Trim frame ranges, filtering the interlaced ones and splicing them back together "conditional" you could do that

You could make it slightly less tedius by marking the ranges in YATTA and letting it sort out the actual Avisynth script, but that's still a lot of work if you have a lot of interlaced content.
(Ok I was only half serious)

Or you could just use Tdeint or some such and feed the interlaced frames to QTGMC. <--- most sane option.
You should get pretty close with the right thresholds and then for anything slipping through just use an overrides file to force those frames to be deinterlaced or not deinterlaced.

[x265]

Is this how i postprocess the residual combs after IVTC?


interp=QTGMC(preset="very slow")
deint = tdeint(edeint=interp, emask=tmm())
tfm(pp=6, micmatching=2, slow=2, clip2=deint)
smartfade(dgm=true)
tdecimate(mode=1)

[LigH]

With my limited theoretical NTSC experience here in PAL land, I would immediately think: "You are doing it wrong. If the original is telecined, don't use deinterlacing. Use Inverse Telecine (IVTC) instead: TFM().TIVTC()"

I don't know if your script makes sense at all. If it does, it would surprise me, but someone would have to explain to me why it works and why it is better or worse than the ^ trivial solution as the first step. At the moment I don't see a valid reason for using QTGMC on telecined material. The temporal progress of the fields is not what a deinterlacer would expect.

[AzraelNewtype]

Originally Posted by x265

Is this how i postprocess the residual combs after IVTC?


interp=QTGMC(preset="very slow")
deint = tdeint(edeint=interp, emask=tmm())
tfm(pp=6, micmatching=2, slow=2, clip2=deint)
smartfade(dgm=true)
tdecimate(mode=1)

You'll have to add FPSDivisor=2 to qtgmc, otherwise interp will be bobbed, but this should work. Whether it's actually worthwhile to use such a slow deinterlacer just for grabbing pixels for match failure is a different question entirely.

[osgZach]

Originally Posted by LigH

With my limited theoretical NTSC experience here in PAL land, I would immediately think: "You are doing it wrong. If the original is telecined, don't use deinterlacing. Use Inverse Telecine (IVTC) instead: TFM().TIVTC()"

I don't know if your script makes sense at all. If it does, it would surprise me, but someone would have to explain to me why it works and why it is better or worse than the ^ trivial solution as the first step. At the moment I don't see a valid reason for using QTGMC on telecined material. The temporal progress of the fields is not what a deinterlacer would expect.

Because IVTC is not flawless and as mentioned, sometimes you have to deal with residual combing (which look suspiciously like interlacing) left-over from field matching. So you deinterlace the frame.

But I'm not sure which post you were replying to, so that's my generic response.

[LigH]

@ osgZach:

I referred to x265's script just one post above my reply; usually I would expect that a straight 3:2 pulldown can be exactly reversed to its progressive original. Except some *censored* cut the video after telecine and destroyed the regular pattern, so the field matcher has to re-adapt it now and then.

[osgZach]

Anime is kind of notorious for all kinds of problems, in this case. Newer stuff is a lot better, but...yeah

[LigH]

Newer ... Anime ... better ... a user of the german doom9/Gleitz board (Selur) reported a Blu-ray of "Galaxy Rangers" being actually worse than the DVD: Not even the full SD resolution was used in an MPEG2 video stream. MPEG2! On Blu-ray!

But yes, real cartoons have such a low original frame rate, that a not-so-smart field matcher may have issues detecting the pattern correctly, due to so many duplicated progressive frames already before the telecine.

[simcut]

Hi all

A quick question, I was previously using the QTGMC 3.32 and noticed there was a small update to 3.33, how do I get the update to work? all I've downloaded is a QTGMC-3.33.avsi file, do I put that in the C:\Program Files (x86)\AviSynth 2.5\plugins folder and delete the 3.33 one?

Thanks

[Selur]

all I've downloaded is a QTGMC-3.33.avsi file, do I put that in the C:\Program Files (x86)\AviSynth 2.5\plugins folder and delete the 3.33 one?

yes, but you should delete the old 3.32 not the new 3.33

[simcut]

Originally Posted by Selur

yes, but you should delete the old 3.32 not the new 3.33

Haha, yes, sorry, was a typo, I obviously delete the old 3.32 :P

Cheers.

[Johnnyas]

I'm trying to use QTGMC with X264 to compress a home video (full hd, 25fps interlaced). I'm using this script:

SetMemoryMax(1400)
SetMTMode(3, 4)
AVISource("F:\DigiVidCam\video.avi",audio=false).AssumeFPS(25,1)
SetMTMode(2)
AssumeTFF()
QTGMC( Preset="Slower", EdiThreads=1 )
Distributor()

Right now I'm using v3.33 of the script, with the modified MT package from the op.

I'm rendering on a quad core i7@2,9ghz, with 8gb ram (and on a SSD disk). The video is 89 minutes, and at first it starts off at around 1,80 fps. Projected completion time was around 50 hours. Not exactly blazing speed, but I'm ok with it - it usually produces very good results.

The main problem is that it slows down. Right now, close to 12 hours in (and close to 10 minutes done of the video), it's at 0,69 fps, with a projected time remain very close to 4 days.

As this happens gradually during the compression, testing takes an awful lot of time. Anybody have any good tip as to where I should start with testing given the slow-down symptom?

(This usually happens when I use QTGMC. I've usually had a bit shorter videos, and also only one every now and then - but I have some more lined up now so it'd be nice if a change in settings can speed things up (well.. other than reducing quality really)).

[Taurus]

@Johnnyas
Just some wild guessess...
Dont use "distributor()" in your script!
x264 gets it's own threading model.
With "distributor" you are multiplying the threads until it gets unstable.
Maybe lower your memorymax, start with "SetMemoryMax(1024)".
Which avi decoder you are using for your avi?
Maybe try another one.
Or give ffvideosource a chance, yes it can decode avi.
Or set SetMTMode(3, 4) to SetMTMode(5, 4).
Without knowing your source it's almost impossible to help you
And maybe a mediainfo.
And why you are using (beta)QTGMC 3.33?
Edit: Which avisynth version?
To get all the benefits from -VIT-'s modded plugins
it's the best to follow the instructions on the first page to the bone.
Especially the Avisynth MT version is important.