Need expert advise on IVTC/Decomb/rePal, etc

[Tommy P]

Hi everybody,

This is my first posting here, so I apologize if someone in this forum has already answered these questions before; I certainly couldn't find those answers, otherwise I wouldn't be asking them again.

I'm trying to compress one of those weird clips that result form a botched PAL -> NTSC DVD conversion. Basically, out of every 6 frames, 5 consecutive ones are interlaced, and the sixth one is progressive.

Before I figured this out, I tried processing it with whatever script GKnot has automatically generated for me, which was this: Telecide(order=1,guide=1).Decimate()

The result was a slightly jumpy playback, with a lot of interpolated frames.

Then I manually edited the script to this: Telecide(order=1,guide=3).Decimate(cycle=6)
This got rid of jumpiness and resulted in a lot fewer interpolated frames. Also, the picture became somewhat blurrier (why?).

But after the first pass, I got a warning saying that there were more frames IVTC'd than initially set to. Also, the resulting AVI file size was suboptimal (675MB instead of one full 700MB CD).

So my first question is: why did I get this warning, and what can be done about it, in order to optimize the file size?

Another thing I discovered with the "show=true" option was that Decimate ruins the pattern for Telecide. Without Decimate, Telecide locks onto the pattern perfectly well. After I add
Decimate, it starts going in and out of pattern. In hindsight this makes perfect sense: after you throw out a duplicate frame the pattern is off, and Telecide gets all confused. I wouldn't mind, but Telecide starts making less than optimal field matching decisions as a result.

Is there any way to apply Decimate, but at the same time keep Telecide happily locked onto the pattern?

Then I was also surprised how many interlaced frames still gets through, despite IVTC. Why so many?

Then I tried using rePal() in combination with DGbob(), or with kernrlbob(4). The outcome was not too good, so I must be doing something wrong. But on the other hand, any "bob" filter creates full frames from individual fields, i.e. creates twice as many frames using only half of available information for each of them. So isn't it logical that you end up with lower "quality" frames? And I don't quite understand what rePal() does. (And yes, I've read the documentation included with it).

Finally, someone said he had success using a combination of rePal() and kernelDeint140()...

So, as you can see now, I'm thoroughly confused. I'd appreciate any ideas very much. Thank you in advance!

[neuron2]

Originally posted by Tommy P
This is my first posting here, so I apologize if someone in this forum has already answered these questions before; I certainly couldn't find those answers, otherwise I wouldn't be asking them again.

I'm trying to compress one of those weird clips that result form a botched PAL -> NTSC DVD conversion. Basically, out of every 6 frames, 5 consecutive ones are interlaced, and the sixth one is progressive. Since your progressive frame count in the cycle does not match reasonable pulldown patterns, you may have field blended video. On the other hand, you say Decimate(6) smooths it out, so it may be that you have misattributed progressive and interlaced frames, and you actually have 25fps pulled down to 30fps by repeating two fields.

Before I figured this out, I tried processing it with whatever script GKnot has automatically generated for me, which was this: Telecide(order=1,guide=1).Decimate()

The result was a slightly jumpy playback, with a lot of interpolated frames.

Then I manually edited the script to this: Telecide(order=1,guide=3).Decimate(cycle=6)
This got rid of jumpiness and resulted in a lot fewer interpolated frames. Also, the picture became somewhat blurrier (why?). It is inconsistent to say there was less interpolation but blurrier video! Changing Decimate() won't affect blurriness, so you must be getting more interpolation if your video is generally blurrier. Maybe you imagined it?

But after the first pass, I got a warning saying that there were more frames IVTC'd than initially set to. Also, the resulting AVI file size was suboptimal (675MB instead of one full 700MB CD). You're mixing up Telecide/Decimate with your encoder now. You can't do IVTC in your encoder if Telecide/Decimate are already doing it.

So my first question is: why did I get this warning, and what can be done about it, in order to optimize the file size? This is not an encoding forum.

Another thing I discovered with the "show=true" option was that Decimate ruins the pattern for Telecide. Without Decimate, Telecide locks onto the pattern perfectly well. After I add
Decimate, it starts going in and out of pattern. That's not possible because the filter chain is unidirectional from Telecide() to Decimate().

In hindsight this makes perfect sense: after you throw out a duplicate frame the pattern is off, and Telecide gets all confused. I wouldn't mind, but Telecide starts making less than optimal field matching decisions as a result. See above. You have to run Telecide() before Decimate().

Is there any way to apply Decimate, but at the same time keep Telecide happily locked onto the pattern? If you can show that this is not already the case, I'll buy you a beer.

Then I was also surprised how many interlaced frames still gets through, despite IVTC. Why so many? Too many questions for one post. Do this: post the two scripts which you think demonstrate that Decimate() affects Telecide(). Then we can try them and see if you are correct.

Then I tried using rePal() in combination with DGbob(), or with kernrlbob(4). The outcome was not too good, so I must be doing something wrong. But on the other hand, any "bob" filter creates full frames from individual fields, i.e. creates twice as many frames using only half of available information for each of them. So isn't it logical that you end up with lower "quality" frames? And I don't quite understand what rePal() does. (And yes, I've read the documentation included with it).

Finally, someone said he had success using a combination of rePal() and kernelDeint140()...

So, as you can see now, I'm thoroughly confused. I'd appreciate any ideas very much. Thank you in advance! You certainly are confused. I respectfully suggest you post your first question/dilemma and learn from the answer. Then hit us with followup questions. Thanks and good luck!