Getting an undersized file

[Tommy P]

Hi everybody!

I've read the sticky on undersized files, but I'm not sure it addresses my situation. So here's my problem...

I'm using GKnot on a movie that seems to be one of those bad PAL -> NTSC conversions (namely, one progressive frame out of six). Initially, I just used the script GKnot has automatically generated for me, which included this line:
Telecide(order=1,guide=1).Decimate()

The result was a slightly jumpy playback, with a lot of interpolated frames. But the file size was right on: exactly 700MB.

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.

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 why did I get this warning, and what can be done about it, in order to optimize the file size?

Thank you in advance!

[Tuning]

Originally posted by Tommy P
So why did I get this warning, and what can be done about it, in order to optimize the file size?

The warning is issued because the no: frames found is lot less than calculated.

On close inspection you can see decimate() function used by GK is actually selecting 1 out of 5 frames in consecutive order. When you change to decimate(6), 1 frame from every consecutive 6 frames are selected. So there will be some frames less in the new encoded file.

To circumvent the problem simply un check " Correct frame count option"

Hope that helps...:)

[Tommy P]

Thanks, Tuning, I'll try your suggestion.

But I'd like to learn more. What exactly is this option doing?

Also, I think your argument may actually be backwards. If I drop 1 frame out of six (as opposed to 1 out of 5), I will thus drop FEWER frames (and keep MORE frames), so the resulting file may only be LARGER.

What I think is happening is this: using guige = 3 in Telecide results in better field matching. So it results in MORE frames being IVTC'd (that's what the warning says anyway), and that's the real reason for my final file being UNDERSIZED. Right? Because being able to recover MORE progressive frames means I need to carry less information in the final file. Am I correct on that?

And also, what I'd like to learn is how do I make GKnot perform the right calculation in the first place?

Thank you very much!

[Tuning]

Originally posted by Tommy P
Also, I think your argument may actually be backwards. If I drop 1 frame out of six (as opposed to 1 out of 5), I will thus drop FEWER frames (and keep MORE frames), so the resulting file may only be LARGER.


Sorry, I got confused now, may be you are right.
Edit: You are right.
Suppose we have clip of 230 frames,
Then in decimate(5)
230/5= 46 frames will be removed.
in decimate(6)
320/5~ 38 frames

So your argument is correct, that decimate(6) will be having more frames than decimate(5)

But here GK thinks it should get the frame count as 230-46=184 f
and actually we get 230-38= 192 f

In this context, GK reduces the total bitrate for compressing the added extra frames and hence final size will be lower.

And this frame count calculation is done only when you check "Correct Frame Count" in Save & Encode dialog box.