Why are there spurious? frames in my interlaced PAL capture - sample clip

[BigMick]

Hi Guys,

I've captured all my old home video in prep for a DVD conversion. This was my setup:

Video 8 camcorder (composite) -> CTB-100 (TBC) (s-video) -> ATi Radeon 9600 XT -> VirtualDub -> HuffyUV 2.1.1 (CCE SP 0.2.5)

I'm now reviewing the footage looking at what post processing I need to do and I've come across something really odd. There seems to be occasional "extra" frames out of sequence and I can't understand why. I'm seeing this by using the following AVS script to look at this clip of the boy walking down the stairs:

http://www.mediafire.com/file/zhh3nzjzwzc/Test6.avi

AVISource("test6.avi")
AssumeTFF()
SeparateFields()

If you look for example at Frames 62 and 64 (in the separated clip) - Frame 64 is a duplicate of frame 62 and is out of sequence - it really shouldn't be there I don't think. The odd thing is that these two have come off different frames (31 and 32) in the original avi/interlaced clip. [s:82d8a2e52c]And comparing frames 31 and 32 (in the raw avi), this particular field is actually shifted down one line, which confuses me as to how it ended up one frame apart in the separated clip - i would have thought it should be consecutive or 2 frames apart in this case depending on field order[/s:82d8a2e52c].

Can anyone shed any light on what might be going on here?? I'm very much a newbie at this, the answer might be something obvious.

Thanks
Mick

[jagabo]

My guess is your TBC or capture device missed a field and/or frame here and there and a duplicate of the previous was added in its place. The fact that large parts of the frame shift from side to side indicates trouble with the tape which is likely to cause such problems.

[BigMick]

Actually on close examination it's an illusion that the frame in question drops by one line, so ignore that bit I said before.

Thanks for the quick reply - that makes sense. The tapes were pretty awful-some of the footage dates back to late 80's early 90's. Without the TBC I did notice the framerate was all over the place and often under 25, so the TBC would have had its work cut out for it. With the TBC I got a solid 25.00 fps. So on consideration I think it's probably a pretty safe assumption that these duplicate fields are coming from the TBC.

Given that, I guess my complaint is that they are duplicates of the previous image for that particular field (odd/even) rather than simply a duplicate of the previous image. This means they are actually out of order now. I'd like to understand if this is a fault in my TBC or the designed behaviour. I guess the problem with using the previous image (from the other field) is it would need to be shifted down by one line and then is in the wrong vertical position. So the timing is better, but the position is wrong. Is this correct? Can anyone provide any information or links on how a full-frame TBC actually deals with an input signal that's not keeping up with the output?

Here's some info on my TBC:
http://www.converters.tv/products/colour_correction_48.html
http://www.questronix.com.au/products/ctb100.htm
It mentions it has "Dual-field full-frame reconstruction" and "The CTB-100 is a digital instrument. The input video is sampled into memory in real-time"

I guess a follow up question is - is it worth worrying about and if so are there any options for cleaning it up? I was thinking maybe there's a function in Avisyth to detect duplicate frames. If I could identify the dodgy frames I could then try to substitute them with a more appropriate frame or drop them. But even if I could do this, I suspect it is likely to introduce its own issues?

Thanks

[jagabo]

It looks to me like the TBC is substituting the previous field so the position of the fields is correct. Given how jumpy and distorted the frames are during those shots I don't think you'll notice the duplicate fields at normal playback speed.

AviSynth has functions for removing duplicate frames but the frames have to be adjacent to each other and (more or less) regularly spaced. The only other option I see is to remove (or substitute) the duplicate fields manually. You could do that by bobbing to 50 fps then manually deleting frames. That will decrease the running time, obviously.

Here's a sample after bobbing, removing duplicate frames, deshaking, cropping away borders, and resizing to 640x480 Xvid AVI:

deshake2.avi

[BigMick]

Wow, you've done extremely well there. Would you be able to share the script you're using (particularly the deshaking part). I was experimenting a bit with the two-pass virtual dub deshaker plugin on a different home vid clip, it worked quite well except in some scenes it seemed to introduce a bad distortion or "wobble" almost like you are swaying on a boat - I'll try and post up a sample.

I've recently discovered this and found it gives excellent results in removing "flicker" throughout my clips, however I think what you've done seems to preserve a bit more detail and is more stable:

i = ConvertToYV12()
mdata = DePanEstimate()
DePanInterleave(i, data=mdata)
FluxSmoothT(15)
SelectEvery(3, 1)

manually deleting frames

What's the easiest way to do that?

Thanks for your help

[jagabo]

First I used TempGaussMC_beta1() to smart bob the video to 50 fps. Since that's a very slow filter I saved the result as a Lagarith encoded AVI. Then I opened that AVI with VirtualDub, stepped through frame-by-frame and deleted the duplicates (mark-in on a dup frame, mark-out on the next frame, cut). Then I cropped the borders, applied the DeShake filter (default settings), and cropped the borders again (DeShake created new black borders). Note the frame rate was left at 50 fps.

I also made a version where I left the duplicate frames and it was hard to tell the difference. The time base wobble in the frames, even after deshaking, made the motion errors hard to see. Duplicates might be more obvious in other shots though -- especially medium speed pans.