How does TFM() work?

[Logan9778]

Hey guys. I'm trying to find out just how TFM() works. I know it does field matching to de-telecine a video, but I'm confused on just what is happening.

Telecine field pattern should be AABBBCCDDD. And in experiments, it looks like the frames made of BB and BC are turned into dupes, because of the field matching. B matches B, and then the third neighboring B also matches. But it looks like D does not make a duplicate frame, which confuses me. I thought there would be two duplicate frames left over to kill. One BB and one DD.

I guessing its doing something different in the way its matching. This is with Mode=0, just straight neighboring match.

Thanks!

[foxyshadis]

It turns AaBbBcCdDd into AaBbCcDdDd, and then it's TDecimate's job to scan the stream and drop DdDd back to Dd (it actually reads hints left in the video as a default best-guess, though there are times it can choose differently, especially in heavily interpolated frames). The basic use is just TFM().TDecimate().

If you were to duplicate BB and DD, then you'd end up with 6 frames in a 5 cycle! Little bit overkill, though TDecimate could still handle that if it had to.

The reason why is mostly historic baggage, Donald Graft already had a field-matcher for VirtualDub in 2001, Telecide, and he developed Decimate later. VirtualDub didn't support frame-rate changes by plugins at the time, there was a strict one-frame-in, one-frame-out cadence, and the Decimate function had to be externally implemented. Almost everything since has left them separate as a convention and a bit of separation of duties, even though they're rarely ever used separately. SmartDecimate is one exception, it goes straight for 5 in->4 out. Even VIVTC in Vapoursynth, which has practically none of the restrictions of Avisynth, still does that.

[Logan9778]

It turns AABBBCCDDDD into AABBCCDDDD

Thanks, but did you mean AABBBCCDDD (less one D than above) in the first string of fields, or do I not have the telecine pattern right?

I don't see how it does it, I guess I'm just going to have to read the code one day. :P

[foxyshadis]

Sorry, yes, I repeated D one too many times in the first, and I edited in to make top/bottom fields clear.

The internals are very complicated in order to speed it up and account for numerous corner cases, but the basic algorithm is: Check if the frame is combed or not. If not (Aa, Bb, or Dd), leave it alone. If so (Bc or Cd), check whether weaving the c with the next frame's C is correct. If so, done! Output Cc and throw in Dd to keep the framecount consistent. If not... well, like I said, all kinds of corner-cases and post-processing to those times when edits probably broke the cadence or left messy combing even in the matched fields. TFM also has a particularly mature ability to detect changes between pure video and telecine, another complication in the code if you enable those modes; it can output pure video as-is or deinterlace it, instead of trying to IVTC it and making a mess.

[Logan9778]

Ah, thanks! That makes it clearer. Yeah, I discovered pp=7, and it does well to deinterlace the weird interlaced spots in the telecined video.

[hello_hello]

Thanks, but did you mean AABBBCCDDD (less one D than above) in the first string of fields, or do I not have the telecine pattern right?

Draw the pattern like this and it might seem clearer.

ABCDD
ABBCD

TFM would check the top field of a particular frame for a match with the bottom field of the same frame, and also the bottom field of the next frame. The best match is kept, and the end result is the top B only has one best match (either of the bottom Bs) while the two top Ds both get matched to the bottom D, creating a duplicate frame.

[Logan9778]

Thanks Hello! That makes perfect sense, and I get two D frames when matching top with bottom and neighbor bottom.

[hello_hello]

I may have goofed on the pattern. The TFM help file, and Wikipedia, show it this way:

ABBCD
ABCDD
Matches:
ccnnc # if TFM(field=0), matching from the bottom
ccppc # if TFM(field=1), matching from the top

c=current, n=next, p=previous

Therefore frame B would be duplicated. Not that it matters. The principle is the same.

[Logan9778]

Lol, yeah, I was wondering. My experiments always showed frame B duplicated.

Thanks for correcting it!

[hello_hello]

Actually.... now I've thought about the previous example again.... the B frame would be duplicated when matching from the top, but it'd be D when matching from the bottom.

That's the way it's explained in the TFM help file too. I should have paid more attention. The principle is still the same though. :)