QTGMC Deinterlacing Script (v3.32)

[simcut]

Hi guys, quick question, with solely interlaced footage, in my avisynth script, do I need to add AssumeTFF() or AssumeBFF() depending on what DGIndex detects as the field order, or does it not matter at all, does QTGMC detect the field order anyway so I dont need those commands in, or do I have to have them in.

Currently I have an avisynth script each set up, one for TFF and another for BFF.

Thanks

[Reel.Deel]

I only add AssumeTFF/BFF when the sequence is clearly out of order.

[LigH]

QTGMC will rely on the field order AviSynth assumes after loading the source clip.

Not all source filters are able to determine the field order correctly (e.g. AviSource will probably assume BFF because the AVI container does not flag it, each VfW codec may have its own default, and BFF is the most common default for DV in AVI); sometimes even the encoding studio flagged the material wrong. In general, better be safe than sorry (to have wasted hours due to QTGMC creating motion "holes" because the assumed order was wrong).

Furthermore, never use QTGMC if there is no regular interlacing (e.g. don't use it on Telecine with 3:2 or worse pulldowns, or even on norm conversion results with blending).

[Boulder]

Originally Posted by LigH

Furthermore, never use QTGMC if there is no regular interlacing (e.g. don't use it on Telecine with 3:2 or worse pulldowns, or even on norm conversion results with blending).

Out of interest, what is a good way to bob when redoing blended crap? I've been using QTGMC since it provides good quality even with non-purely interlaced material. Maybe it's just some of the post-processing stuff there that works well, I don't know.

[Sharc]

Originally Posted by Boulder

Out of interest, what is a good way to bob when redoing blended crap? I've been using QTGMC since it provides good quality even with non-purely interlaced material. Maybe it's just some of the post-processing stuff there that works well, I don't know.

Blended crap = blended fields or blended frames?
Dependiong on the root cause for the blending srestore() often helps. It might be a bit tricky (trial and error) to find the original (progressive) framerate if it is not compliant with one of the common (standard) rates.
Blended fields are more difficult or hopeless to fix, I think ....

[Boulder]

Oh, I meant preprocessing (=bobbing) the clip to feed to SRestore. SRestore itself works quite well in most cases if the pattern is constant.

[Sharc]

I normally use tdeint(mode=1) as a bobber,
or QTGMC(input type=0)
followed by srestore(omode="pp3"), possibly followed by
tdecimate() for removing double-blended fields.

You may already have tried this though ....

[DJ-1]

Hi, if I want a good analysis of source material I need to have trimmed my source from time to time. I usually use dvd shrink & use its cut feature but have read about programs not doing 'clean-cuts'.
Can someone recommend a 'clean-cutting' cutter?, thanks.

[LigH]

For MPEG2 sources like on DVD Video: Cuttermaran or MPEG2Schnitt. They will be able to cut GOP-wise, or even frame-accurate with smart re-encoding if you use one of the MPEG2 encoder "provider" modules (e.g. for HC).

[Music Fan]

Dvd-Shrink cuts correctly on I-frames because it can not re-encode (no smart rendering).

[Music Fan]

Originally Posted by Sharc

I normally use tdeint(mode=1) as a bobber,
or QTGMC(input type=0)
followed by srestore(omode="pp3"), possibly followed by
tdecimate() for removing double-blended fields.

What does "double-blended fields" mean ?
Does your script work with blended fields from interlaced videos (resized without de-interlacing) ?

[Sharc]

Originally Posted by Music Fan

What does "double-blended fields" mean ?

Both fields of a frame are blended.

Does your script work with blended fields from interlaced videos (resized without de-interlacing) ?

I don't know, but I doubt. You would have to try and see whether you get some improvement. There are probably better scripts for that purpose. Resizing of interlaced content without prior deinterlacing is bad.
Perhaps someone else could chime in ....

[simcut]

Originally Posted by LigH

QTGMC will rely on the field order AviSynth assumes after loading the source clip.

Not all source filters are able to determine the field order correctly (e.g. AviSource will probably assume BFF because the AVI container does not flag it, each VfW codec may have its own default, and BFF is the most common default for DV in AVI); sometimes even the encoding studio flagged the material wrong. In general, better be safe than sorry (to have wasted hours due to QTGMC creating motion "holes" because the assumed order was wrong).

Furthermore, never use QTGMC if there is no regular interlacing (e.g. don't use it on Telecine with 3:2 or worse pulldowns, or even on norm conversion results with blending).

Thank you for your advice man, much appreciated!

[hello_hello]

Would it be normal for QTGMC to be slower when working with non-mod16 video than if it's mod16?

I've been re-encoding some old video which is mostly 720x576 and running QTGMC in progressive mode to clean it up a little.
QTGMC(InputType=1, Ezdenoise=1)

I noticed every so often one of the encodes would take much longer. A little investigating seems to indicate it's due to a mod4 width. If I resize to mod16 in the script before QTGMC the speed goes back to normal, but that's not ideal as I'm also resizing after QTGMC.

It's not the end of the world and something I probably only noticed because the old dual-core I'm using is pretty slow anyway. When the resolution is 720x576 it only manages about 5.5fps, but CPU usage sits on 90%-100%. When the width is mod4 (ie 716x576) it drops to about 2.8fps and CPU usage hovers around 70%. There's a couple of encodes which I think ran even slower and they may have also had a mod4 height. I'd need to go back and do some more testing to confirm that.

I've tried QTGMC 3.32 and 3.33. I've checked to see whether I'm still using the QTGMC recommended versions of the various plugins and went back to the recommended versions where I wasn't but that didn't seem to make any difference. Avisynth 2.6.0.4, Windows XP.

Thanks.

[Boulder]

It could be memory alignment playing tricks on you (see Crop in Avisynth's documentation). You could try using Crop with the align=true option to get around it. Or Crop(0,0,-0,-0,true) if you've already cropped the video elsewhere.

[hello_hello]

Thanks Boulder.

I ran a test with a source video with a resolution of 716x576.

With this script it runs at about 2.8fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
crop(0,0,-0,-0,true)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

With this script it runs at 5.1fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
Spline36Resize(720,576)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

I even tried a second PC (quadcore). Being slow and running in single threaded mode, I'd normally run two QTGMC encodes at the same time. When I do, the encode of the video with a mod16 resolution runs a fair bit faster (close to 2x) than the one with the mod4 resolution.
I've tested without fpsnum=25, fpsden=1 and threads=1, but they don't seem to be causing it. QTGMC's Ezdenoise doesn't seem to be the culprit either.

[LigH]

Uh, scaling twice... I may rather have added a border and cropped as much more.

[asarian]

Originally Posted by hello_hello

Thanks Boulder.

I ran a test with a source video with a resolution of 716x576.

With this script it runs at about 2.8fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
crop(0,0,-0,-0,true)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

With this script it runs at 5.1fps

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
Spline36Resize(720,576)
QTGMC(InputType=1, Ezdenoise=1)
crop(4, 4, -4, -6)
Spline36Resize(656,480)

I even tried a second PC (quadcore). Being slow and running in single threaded mode, I'd normally run two QTGMC encodes at the same time. When I do, the encode of the video with a mod16 resolution runs a fair bit faster (close to 2x) than the one with the mod4 resolution.
I've tested without fpsnum=25, fpsden=1 and threads=1, but they don't seem to be causing it. QTGMC's Ezdenoise doesn't seem to be the culprit either.

Instead of Spline36Resize(720,576), why not just AddBorders (4, 0, 0, 0) or something? The way you do it now, you're losing data.

Several QTGMC options even require mod16; so, always best to pad your source up to mod16 to begin with, I'd say.

[hello_hello]

In the end, I've used this script to solve the slowdown problem, while wondering why I didn't just think of it in the first place......

LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("E:\video.mkv", cachefile="D:\video.ffindex", fpsnum=25, fpsden=1, threads=1)
AddBorders(4,0,0,0)
QTGMC(InputType=1, Ezdenoise=1)
crop(8, 4, -4, -6)
Spline36Resize(656,480)

I use QTGMC for noise reduction quite a bit and I've not paid much attention to the source video dimensions in the past. Next time I'll try something similar if the source isn't mod16 to test whether the speed difference is normal.

Edit: I found the solution while you guys were suggesting it too, but I didn't see your posts until I submitted this one.
Thanks!

[-Vit-]

Kudos to the VapourSynth guys for getting QTGMC native. Wonder how well it works.

Just passing by to say hello - happy to see the script still being used. My avisynth development fell by the wayside when other things came up. Today I needed to do some video processing for first time in a long time. I found I didn't even have a working avisynth setup, lol. I seem to have lost the latest QTGMC version I had been working on. Probably for the best, it was getting even more complex...