IVTC or Yadif?

[pooksahib]

I've started work on a PAL DVD with mouseteeth. "Bob" reveals movement every second frame and my notes say "...IVTC using TFM". Being curious, I ran the 'Analyse' function in MeGUI and it pointed me to Yadif. I did some googling on 'IVTC vs Yadif' and ended up reading about TempGauss. Said manono in 2009: "If quality and not encoding time is your main concern, then nothing beats TempGaussMC."

I installed TempGaussMC_beta2.avsi and the required plugins but couldn't get the script to run.

My questions then: Do I definitely NOT need QTGMC where movement is every two frames? Which to use: IVTC, Yadif or something else?

Many thanks.

[Alwyn]

Attach a sample.

TempGaussMC

That is (Q)TGMC. (Q for Quick).

[pooksahib]

Thanks, Alwyn. One lives, one learns... I did edits using Yadif and tfm (TIVTC) but can't tell the difference. I'll stick with Yadif solely based on another manono uttering: "Yadif is, in my opinion, the fastest good deinterlacer."

[manono]

Maybe the fastest, but far from the best. That must have been a long time ago I wrote that. I use a different fast bobber now.

And you don't IVTC a PAL video. TFM, maybe. And if TFM is the way to go, that produces better quality than any deinterlacer or bobber.

[pooksahib]

That was back in 2009, manono. Hello, by the way.
When I first used Bob() on this DVD it was a quite distinct 'movement every 2nd frame'. But I've done it again and don't really know what I'm seeing - it's kind of one step forward one step back but still moving forward (if that makes sense). Perhaps someone would be kind enough to look at this sample, explain HOW they analysed it and what's best to do with it when doing an avisynth edit. My grateful thanks.

[Sharc]

The video content is progressive, just flagged as interlaced, TFF, and phase shifted. Not unusual for PAL. Don't deinterlace but rather field-match it using TFM() and you will get the 25fps progressive frames.

LWLibavVideoSource("sample.MPG")
TFM()

[pooksahib]

Thank you, Sharc. I think I've been doing this wrong all along. I'd open the VOB's with MeGUI and look at the preview for combing thinking that no combing=progressive and combing=interlaced. This DVD does have combing so what is it you did to establish that it's "progressive, just flagged as interlaced, TFF, and field shifted"? Thanks again.

[Sharc]

Thank you, Sharc. I think I've been doing this wrong all along. I'd open the VOB's with MeGUI and look at the preview for combing thinking that no combing=progressive and combing=interlaced. This DVD does have combing so what is it you did to establish that it's "progressive, just flagged as interlaced, TFF, and field shifted"? Thanks again.

Separate the fields and step through the fields in 2 tests, using AviSynth:

AssumeTFF()
SeparateFields()

you will see motion with every 2nd field advancement only but motion is smooth, means it is actually progressive video

then using

AssumeBFF()
SeparateFields()

you will get your jerky forward-backward jitter motion. Means it is phase shifted.

[Alwyn]

Can be analysed easily in VDub; simply apply the Bob Doubler+TFF/BFF or Deinterlace filter (Yadif+Double Rate BFF/TFF), then step through.

[hello_hello]

Thank you, Sharc. I think I've been doing this wrong all along. I'd open the VOB's with MeGUI and look at the preview for combing thinking that no combing=progressive and combing=interlaced. This DVD does have combing so what is it you did to establish that it's "progressive, just flagged as interlaced, TFF, and field shifted"? Thanks again.

If you bob de-interlace where there's movement and every frame is unique, then it's interlaced.
For PAL with phase shifted fields, bob deinterlacing should still result in a unique frame, a duplicate, then a unique frame and a duplicate etc, as it would for progressive video (as sharc explained, if the picture jumps back and forth after bob de-interlacing, then you'll need to use AssumeTFF or AssumeBFF first).
If each frame is repeated after bob de-interlacing PAL then it doesn't need to be de-interlaced (even though it might look combed before de-interlacing due to the phase shifted fields) and field matching with TFM to put the progressive frames back together should do the trick.

PAL - bob deinterlace - no repeated frames - bob deinterlace.
PAL - bob deinterlace - each frame is repeated - TFM instead.

[jagabo]

Say you have four film frames:

A B C D

and they are broadcast top field first (interlaced analog video is a sequence of fields, not frames):

A a B b C c D d  (upper case is the top field, lower case is the bottom field:

Since analog video is an alternating sequence of top and bottom fields a capture device can start capturing with either top or bottom field. If the above sequence is captured starting with a top field, then weaving in the next field, a bottom field, you will get top field first video frames:

Aa  Bb Cc Dd

The resulting frames will look progressive. But if the capture device starts with a bottom field, weaves in the next field, a top field, you will get bottom field first video frames:

aB bC cD

Each video frame consists of a field from one film frame and the next film frame. Those frames will look interlaced even though the original source was progressive film frames. The frames can be made progressive again simply by recombining fields:

a B b C c D d (back to a sequence of fields)
(discard a) Bb Cc Dd  (recombine as frames, skipping the initial frame)

[Alwyn]

Very helpful, Jagabo

The frames can be made progressive again simply by recombining fields

How do we "recombine" the fields?

[hello_hello]

How do we "recombine" the fields?

Generally with TFM() from the TIVTC plugin if you're using Avisynth.
In it's basic mode of operation, TFM checks (assuming it starts with the top field) the top field of the current "frame" to see if it matches the bottom field of both the current and the previous "frames". The best match is used to output a progressive frame. If there's any residual combing it de-interlaces the parts of the frame that need it.

As a side note, when that process is run on NTSC video with 2:3 pulldown (where fields are repeated) it should result in one field in each group of five "frames" being matched twice, creating a duplicate frame in each group of five for TDecimate() to remove.

[Alwyn]

Thanks HH.

[Sharc]

Very helpful, Jagabo

The frames can be made progressive again simply by recombining fields

How do we "recombine" the fields?

TFM() or trim the first field off.

[pooksahib]

Excellent clarification by hello_hello and jagabo. Many thanks indeed. Daft question probably but what exactly is a 'field'? In my mind, I see 'frame' as a photgraph and so a progressive movie is a series of photographs. How would I envisage a field?

[hello_hello]

pooksahib,

Back in the analog days when there weren't any pixels as such, there were only scanlines running across the picture. So (for simplicity) a PAL picture would have 576 scanlines. If you separated out all of the odd numbered scanlines that'd be one field, say the top field, and all the even numbered scanlines would be the bottom field. That's the way analog images were recorded and displayed. The camera would record the even scanlines, then the odd scanlines, making each field a separate moment in time (causing the combing effect in an interlaced image when it's displayed as progressive without being de-interlaced). A CRT TV would draw the picture on the tube the same way. The electron gun would run down the screen drawing the even scanlines, then it'd go back and draw the odd scan lines. It was a clever idea in it's day, as if the electron gun drew the whole picture from top to bottom it'd be noticeably flickery at a refresh rate of 60Hz for NTSC or 50Hz for PAL. Drawing the picture in an interlaced fashion helped reduce the visible flicker, made motion look a bit smoother, and also reduced the amount of bandwidth needed to broadcast the picture.

When you bob de-interlace a picture, each field is interpolated into a full frame, converting 50i (50 fields per second) into 50p (50 frames per second). If you just de-interlace by merging the fields into one progressive frame the output is 25 fps but it tends not to be as good as decent bob de-interlacing. Yadif() de-interlaces to 25p while Yadif(mode=1) bob de-interlaces for 50p.

If you're interested, you can read about how repeating fields with 2:3 pulldown (telecine) was used for NTSC here. It effectively converts a 24fps progressive picture into 60i.

[pooksahib]

Nicely explained. Thanks, hello_hello.

[jagabo]

Excellent clarification by hello_hello and jagabo. Many thanks indeed. Daft question probably but what exactly is a 'field'? In my mind, I see 'frame' as a photgraph and so a progressive movie is a series of photographs. How would I envisage a field?

https://en.wikipedia.org/wiki/Interlaced_video

In short, a field is half the frame, either every even numbered scanline , or every odd numbered scanline. Old interlaced CRT TVs display one field at a time, alternating between even and odd fields.

[pooksahib]

Gotcha. Thanks, jagabo.

[pooksahib]

My work on this particular DVD has been good with TFM(). It's a basic quality DVD, though, not the sharpest of picture. Is there anything worth putting between the brackets of TFM? I tried (cthresh=-1, MI=0) but couldn't notice any difference from bare TFM().

[Selur]

TFM isn't for sharpening, but for matching fields. If you want to sharpen the picture, use a sharpener.

[Alwyn]

Give LSFMOD a crack.

[hello_hello]

My work on this particular DVD has been good with TFM(). It's a basic quality DVD, though, not the sharpest of picture. Is there anything worth putting between the brackets of TFM? I tried (cthresh=-1, MI=0) but couldn't notice any difference from bare TFM().

I often use QTGMC in progressive mode for cleaning up the picture a bit, especially for DVDs. It also tends to sharpen a little.
Try something like:

TFM()
QTGMC(InputType=1, EzDenoise=1.0, Preset="medium")
GradFun3() # from the dithertools plugin to prevent banding

Or you can do the same using dogway's version of those functions.
They may be a little faster.
https://github.com/Dogway/Avisynth-Scripts/tree/master/MIX%20mods

TFM()
QTGMCp(InputType=1, EzDenoise=1.0, Preset="medium", gpuid=-1) # gpuid enables CPU processing rather than GPU
ConvertBits(16)
GradFun3Plus()
ConvertBits(8, Dither=0)

[pooksahib]

Thanks guys, and especially to hello_hello. Adding QTGMC(InputType=1) makes a noticeable difference.

[jagabo]

If you're going to use QTGMC's EZDenoise also set DenoiseMC=true.

[hello_hello]

Thanks guys, and especially to hello_hello. Adding QTGMC(InputType=1) makes a noticeable difference.

I'd also recommend using GradFun3 if you can.

If you're going to use QTGMC's EZDenoise also set DenoiseMC=true.

I'd completely forgotten about the DenoiseMC argument.
I'll have to try a comparison with and without it and hope I haven't been doing it wrong for a long time.