restore progressive video from unusual source

[igorert]

Hiya folks,

I'm dealing with an NTSC DVD transfer with a fairly unusual pattern. After applying Telecide with default guidance, I get the following pattern, which is fairly stable throughout the video:

_ _ D _ _ D _ _D _ D _ _ D _ _ D _ _ D _ D

where D denotes a duplicate frame. Nearly all telecided frames are actually progressive according both to their looks and the debug info shown by Telecide. Now, is there any way I could restore the original progressive stream out of this sequence? I couldn't figure out a way to make Decimate follow these varying cycles...

If a similar question has been asked numerous times already - my apologies, I couldn't find anything by searching the forums - please just post a link to the relevant thread...

[igorert]

Let me try to rephrase. The ivtc-tut has this snippet:

"For example, if you put Telecide(Post=False) into your script, and if 1 is a movement frame and 0 is a duplicate frame, and if you see a pattern like this:

1101011010,

then you have 4 duplicate frames in 10 frames, or 12 dups out of 30, or an original frame rate of 18fps. Then if you use the following script, you can remove the duplicate frames and return the video to its original frame rate:

Telecide().Decimate(Cycle=4).Decimate(Cycle=5) #which brings it down to 17.982fps

What I don't understand is how one comes up with the Decimate cycles of 4 and then 5 given the pattern above. An more detailed explanation would be greatly appreciated...

[neuron2]

Looks like Decimate(5).Decimate(4) is correct (i.e., there is a typo).

Does that make better sense to you?

[gameplaya15143]

Use tdecimate() with an override script. You can set the decimation pattern manually. I forget the name of the filter package though, but a quick search should tell you. :)

[igorert]

Does that make better sense to you?

Yeah, sorta - thanks for the reply; I can now see how those cycles work though picking the right cycles still sounds like a guessing game to me. That is, I can see when the cycles are right but have no deterministic algorithm for picking them beyond looking at the pattern and trying to play with different cycles.

So here is what I figured for the ivtc-tut example. I'll use X for the "decimated" frames and commas to separate each Decimate cycle. After the first Decimate(5) cycle we'll get the following sequence:

11X10,1101X, 11X10,1101X, etc.

Note that we don't know which of the 2 dupes in each cycle of 5 will be actually removed (the Decimate docs say that the "most similar" frame is nixed). Fortunately, this doesn't matter, since in either case we're left with cycles of 4 with a single dupe per cycle (the following sequence is obtained by removing X's from the above):

1110,1101, 1110,1101, etc

So it's now clear that another cycle of Decimate(4) will remove the remaining dupes.


Now, in my case Telecide().Decimate(3).Decimate(22) produced a nice progressive stream of ~19fps. However, I'm still not very clear about how that worked so I would appreciate some clarification.

So in my case the pattern was:

11011011010 11011011010 11011011010 etc.

I noticed that in the large part of the pattern there is one dupe every 3 frames so I tried to see what's going to be left after Decimate(3). I'll use X for the "decimated" frames and commas to separate each cycle of 3 frames:

11X,11X,11X,1X 1,1X1,1X1,1X1,? 11,?11,?11,01X, the sequence repeates itself from here.

Now, everything is clear up to the point where first "?" appears - prior to that point there was exactly one dupe per each cycle of 3 and it was decimated. However, starting with the first "?11" cycle, the "?" frame is actually a dupe of the last frame from the previous cycle. Checking the Decimate(3) output in VDub, it looks like that frame is still properly removed but I'm not sure how that happens - does Decimate(3) automatically readjusts its "pattern"? I thought it'd only do that when it gets pattern guidance from Telecide, i.e., when following Telecide(guide=1)? Am I missing something or is Decimate actually "smarter" than I thought?

Anyway, assuming that Decimate(3) completed by removing "?" frames as well, the rest is pretty easy. What we have now is the following pattern:

1111111111111111111101 1111111111111111111101 etc.

That is, we have a pattern with 1 dupe per 22 frames and Decimate(22) takes good care of that.

[neuron2]

Decimate() always compares each frame in the cycle to the frame's previous frame. So the ? frames are compared to the last frame in the previous cycle.

IIRC, TDecimate() can do N-in-M decimation directly. You may want to experiment with that.

[igorert]

Decimate() always compares each frame in the cycle to the frame's previous frame.
Thanks a lot for the explanation, that's the piece of information I was missing!

I've been thinking about giving TDecimate a try too, maybe next time ;)