But isn't IVTC ALWAYS better than Force Film?

[Alcacia]

I have to admit that I am absolutely mystified regarding the pop-up warning that you get in GK when you activate the IVTC option. To scare users away from this seems just plain irresponsible.

Unless your source is 100 Percent FILM (yes, 100 Percent and not just 95 Percent), then I think you will be better off not using the Force Film option in DGIndex, but instead using the IVTC option in GK.

For those who do not know, the IVTC option in GK merely enables the excellent Decomb filter by Donald Graft. The intelligent field-matching of Decomb will ALWAYS be better than the "dumb" decimation and duplication which results from Force-Filming sources which are not 100 percent FILM. It is even possible in the case of 100 percent film, that some small field order irregularities could still give Decomb the edge.

I recently did a test of a source that was 99 percent film. In one encode, I used Decomb. In the other encode, I used Force Film and Kernal Deinterlace. For both encodes, I encoded using XVID at full quality (i.e., I used "2 Pass - 1st Pass" mode and enabled the full quality 1st pass option)....these encodes were thus "constant quality" encodes.

The encode using Decomb was not only a bit smaller, but also of better quality. I say "better quality" because the Force Film sample exhibited the horribly irritating "dot crawl" or "marching ants" defect in some scenes, and the Decomb sample did not.

So my question to all you Force-Filmers out there is this - unless you are in a big hurry to do your encodes, why use Force Film when you can use IVTC?

[Guest]

On a pure 3:2 source, Force Film is better. The field matcher in Telecide() is not perfect, so you'll emit some combs and have to deinterlace them.

This makes little sense to me:

"It is even possible in the case of 100 percent film, that some small field order irregularities could still give Decomb the edge."

Force Film is also a lot faster so that's a good reason to use it if you can.

But I'm very happy that you like Decomb. :)

[niamh]

I have to admit that I am absolutely mystified regarding the pop-up warning that you get in GK when you activate the IVTC option

well, 2 things:

1) it's only in the advanced avs window
2)its developer is a PAL user ;)

[len0x]

Originally posted by Alcacia
I have to admit that I am absolutely mystified regarding the pop-up warning that you get in GK when you activate the IVTC option. To scare users away from this seems just plain irresponsible.


Its there since the beginning of time :) It was used to scare off newbies indeed, because in most cases with proper mastered material(even with 98-99% of FILM) you'd better off doing FF instead of IVTC. I do agree that now that there are simpler tools available for newbies that warning can be removed.

Originally posted by Alcacia
In the other encode, I used Force Film and Kernal Deinterlace.

So you decided to deinterlace 99% progresive material and then complain that it doesn't look good? :)

The key here is the nature of FILM percentage: _very_ rarely you have non FILM parts in the middle of a movie. Most common case: its credits or logos in the beginning and ending of a movie (that usually 30fps progresive/interlaced). This means that you can safely use FF on such source without having any implications on the main movie itself.

[Alcacia]

Well, len0x, I made a bad assumption about Kernal Deinterlace....You see, I had worked with Donald Graft's FieldDeinterlace filter before. With FieldDeinterlace, there is a threshold parameter for the detection of combed frames -- in other words, *ONLY* the combed frames are touched. I assumed Donald's KernalDeinterlace filter worked similar, but I guess not.

I had examined my test source within the GK gui, and noticed plenty of combed frames...in fact, it seemed like there was a combed frame at every scene transition (editing *after* telecine?). Naturally, I didn't want to waste bitrate encoding combed frames, so that is why I used KernalDeinterlace, under the assumption that it would only deinterlace those transitional combed frames. Well, next time I will be smarter and use FieldDeinterlace instead!

I am quite sure that KernalDeinterlace is to blame for the dot crawl. I just wished I knew more about dot crawl, and how it could be fixed, because I have some AVI's where the dot crawl has already been encoded, and I would like to re-encode via AVISynth to filter it out.

Personally, I think GK should pop up a warning dialog whenever you try to activate KernalDeinterlace! For those following this thread, I am going to try to get ahold of my test source material again and do another comparison test, this time without using KernalDeinterlace...I'll also provide precise numbers for everything!

Oh, and I'll have to thank DG for his reply...it's always nice when the God of Inverse Telecine deigns to speak to lesser beings:)

[len0x]

Oh, I wasn't trying to attack KernelDeInt in this case (in fact its my favourite deinterlacer and I prefer it to FieldDeinterlace). KernelDeInt has threshold parameter as well, so it can be tuned to your liking.

If after FF you're able to see lots of combing then you should never use FF on that source (no deinterlacer will make it look good anyway) - probably flags are out of order (not a proper mastering), so you have to use IVTC via decomb. If you switch FF then on such source you'll be loosing good (non-duplicated) material while still having combing...

[Alcacia]

lenOx, although KernalDeInt does have a threshold parameter, its threshold parameter is specifically said to refer to "motion detection", whereas the threshold parameter of FieldDeinterlace refers to "combed frame detection". Check out the filter documentation.

Although KernalDeInt may be better suited to the deinterlacing of pure interlace material, It appears to me that FieldDeinterlace is better for the deinterlacing of combed frames which result from stray fields or improper telecine.

I might like to fine tune this conversation by making a distinction between "combed frame" and "interlaced frame"

"combed frame" = frame consisting of 2 fields which are separated by 1/24th of a second (such as resulting from telecine)

"interlaced frame" = frame consisting of 2 fields which are separated in time by 1/60th of a second (such as sourced by a handheld videocam)

Lots of things can cause FILM to be less than 100 Percent. But if you see combed frames in your source after FF, then I think you should use IVTC and not FF. If the Non-FILMness of your source is due solely to static scene duplication, or small segments of interlaced frames, then you may as well use FF. If the amount of interlaced frames is in any way significant (i.e., true hybrid), then you shouldn't do IVTC OR FF, but instead deinterlace only.

The 95 percent rule isn't horrible, but it is misleading. In the source I was dealing with, percent FILM was near 99 percent, but the 1 percent Non-FILMness was due entirely to combed frames....in this case, IVTC was the better choice.

In a hard-telecined source, FILM will be 0 percent, but you should still IVTC.

Furthermore, you could imagine sources with, for example 80 percent film in which the Non-FILMness is almost entirely due to static scene duplication....in this case, FF will be the best option...but only because it is *faster* than IVTC.

[len0x]

Originally posted by Alcacia
lenOx, although KernalDeInt does have a threshold parameter, its threshold parameter is specifically said to refer to "motion detection", whereas the threshold parameter of FieldDeinterlace refers to "combed frame detection".

True, what was I thinking :)

Originally posted by Alcacia
But if you see combed frames in your source after FF, then I think you should use IVTC and not FF.

Didn't I say the same?

P.S. hybrid sources can be handled via decomb much better than with FieldDeinterlace, given than you manage to find good threshold for decimate.

[manono]

Hi-

...that is why I used KernalDeinterlace, under the assumption that it would only deinterlace those transitional combed frames. Well, next time I will be smarter and use FieldDeinterlace instead!

If you're talking about using FieldDeinterlace to deinterlace those few remaining interlaced frames after Force Film, then I hope you're using it with the Full=False parameter. If not, the whole thing will be deinterlaced, just as does KernelDeint. Since you didn't mention that, your reasoning is just as flawed as it was when using KernelDeint after ForceFilm.

If the amount of interlaced frames is in any way significant (i.e., true hybrid), then you shouldn't do IVTC OR FF, but instead deinterlace only.

I'm with len0x on this. For most sorts of hybrids, there's only a small percentage of pure interlaced material. I'd also like to get it down to 23.976 using one method or another. But I certainly wouldn't just deinterlace it. The bitrate savings are so significant that I can put up with a certain amount of resulting jerkiness or blending.

[Alcacia]

Good points manano...

As promised, I did a more adequate test.

The test clip is, in fact, 98.43 percent film. It seems that many of the scene changes and camera angle changes are done "in the middle" of a frame...in other words, at each change, there is a frame with one field from the current scene and one field from the scene that is being switched to. These combed transition frames are barely noticeable on a progressive display.

I did full-quality XVID encodes. Here are the resulting file sizes, scaled to the size of the Decomb encode.

FF,FieldDeinterlace(full=false) = 0.815
FF,FieldDeinterlace(full=true) = 0.932
Decomb = 1
FF = 1.019
FF,KernalDeinterlace = 1.063

FieldDeinterlace made the video moderately more compressible, but there were noticeable artifacts introduced, even with full=false. The transition frames became very nice looking blends, though.

KernalDeinterlace not only made the video *less* compressible, but by far gave the worst quality output, with a *very* noticeable and irritating dot crawl.

Decomb gave great results, with no noticeable artifacts (except for the first 2 frames). The combed transition frames seemed to just disappear, as it was apparently able to do successful matching at the transitions.

Not much compressibility difference between Decomb and FF for this high film value.

FF took 4 minutes, all the other samples took 5 minutes. (sorry, not much resolution on the time). So, it's up to you whether you want to say FF is "a lot faster"

[manono]

No, actually I agree with you; it's better to be safe than sorry. More times than I'd like to remember I've finished an encode, found interlacing in a few places after having used ForceFilm, and then had to do it all over again. In such cases, any time saved with ForceFilm is negated. I say as much in our DVD2AVI tutorial.

You mentioned FieldDeinterlace artifacts. In my opinion, the default settings are conservative, and should be tweaked (i.e., loosened up), in many cases. Otherwise, thin lines (power lines, or lines in a brick wall, or in steps, for example) may be seen as interlacing, and get the treatment, with the resulting aliasing/jaggies/shimmer (with the Blend=False setting, anyway). Decomb and its various parts can often be improved with tweaking before encoding. It takes time to first, understand the settings, and second, use them, but it's worth it in the end. It's all well explained in the docs.