Every 6th Frame is a repeat-How to Fix

[poisondeathray]

Apply filldrops stick with result.

But the 30FPS=>30FPS with filldrops will have judder on any display (even a judderless display), unless you decimate first.

looked fine to me in post #11

No, there are small jumps in the motion for FillDrops.Mp4 (it improved over the original, but it's not smooth, and technically wrong)

Filldrops will produce judder on content that was 25p and converted to 30p by inserted duplicates (ChangeFPS type conversion) - it's mathematically incorrect. The space/time "distance" of interpolated frame will not match the distance space/time other surrounding (original) frames

Filldrops would be correct approach if a frame was dropped, and an inserted duplicate took the same location (hence the name "filldrops"), this would give the correct "equal distance between frames" .

I'll try to explain more clearly, or show a more clear demo /graphic with linear motion if it doesn't make sense

[Selur]

Hmm,... okay. Not totally sure it get 100%, but enough that I see your point.
So the only good solution would be to use SelectEvery (if the pattern, of the repeated frame, is fixed) or (T)Decimate (if the pattern might/does change).
Thanks for your patience.

Cu S

[poisondeathray]

On original 25fps content, each frame is 40ms apart (1/25 = 0.04), "equally spaced apart" in terms of time and distance

A ChangeFPS style conversion to 30fps inserts a duplicate every 5th ,6th frame .

The motion of the original frames' content doesn't change . If an object from the original 25fps sequence moved linearly, say 10 pixels to the right per frame, it would go 0,10,20,30,40,50,60 in terms of x-position

After ChangeFPS, it the x-position would look like (where the 0,0 and 50,50 are the inserted duplicate frames; or it might be slightly different depending on where in the cycle you are counting from)

0,0,10,20,30,40,50,50,60,70....

After filldrops, the 2nd frame of the duplicate pair will be interpolated from the frame before and after. An "inbetween" frame 50/50 distance between the 2 neighbors
0,5,10,20,30,40,50,55,60,70...

The distance for the "5" and "55" are half the distance compared to the "normal" frames which have a delta distance of 10. This will appear as judder, because the object that originally moved linearly , will speed up and slow down

[Selur]

Nice, thanks for the detailed explanation.

[johnmeyer]

Thanks John, hopefully this will be the end of this exercise, my head is hurting. You mention TFM, I read the wiki, but what is the actual syntax/example for the three basic parameters , especially the PP? The wiki is characteristically hazy: "int PP. string ovr,".

You usually don't need to do anything except put this:

TFM()

just before the TDecimate call.

This is my basic IVTC script to go from 29.97 interlaced NTSC telecined material to 23.976 progressive.

AssumeTFF() 
tfm(display=false) 
tdecimate(cycleR=1,cycle=5) #defaults are cycleR=1 and cycle=5

(Always make sure you get the field order correct when doing IVTC.)

From the Wiki: "TFM is a field matching filter that recovers the original progressive frames from a telecined stream."

If the telecine pattern has variations, TFM will provide hints to TDecimate so it adapts.

I have not tried it on your source, so I don't know if it will fix your problems, but since it takes five seconds to add "TFM()" to your script, you should at least try it.

[Alwyn]

I have not tried it on your source, so I don't know if it will fix your problems, but since it takes five seconds to add "TFM()" to your script, you should at least try it.

John, I added TFM but to my untrained eye I couldn't spot any difference. I think my video is a simple case of, consistently, an extra frame every 5, so cycle 6 has fixed it nicely.

[Alwyn]

No, there are small jumps in the motion for FillDrops.Mp4 (it improved over the original, but it's not smooth, and technically wrong)

@Selur, I think that was what I was trying to say when I incorrectly described it as variable speed. Stepping through with the arrow keys, the movement just seemed to be a bit variable.