Decomb and weird telecine pattern

[segfault]

I've capped a couple of 60s Batman episodes from DirecTV that I'd like to hang onto as SVCDs, but I've hit a little snag trying to IVTC them. The telecine pattern doesn't seem to match the standard 3:2 pattern, and I can't get telecide to give me proper combing detection.

Instead of the usual NTSC 3:2, the pattern is
pppiipppiipppiippii
The 3:2 pattern runs 3 times, but then there's a 2:2 pattern on the 4th time through.

Regular Telecide(order=1).Decimate(cycle=5) gives me jerky video with a lot of combing getting through. I've played around with the various thresholds, and I've tried to create an override file with the ovr option that will force the pattern, but no matter what I try I can't get a proper IVTC.

Any ideas on how to handle this material and why the pattern is so odd?

[edit] BTW, this is a perfect capture with 0 dropped frames, so dropped frames are a non-issue.

[Dark-Cracker]

hi,

perhaps should u post a little sample of your movie this will help people to made tests on best setting to ivtc your material.

++

[manono]

Hi-

It's probably Telecide(Order=1).Decimate(6).Decimate(19), but as Dark-Cracker says, a piece of the source would be good.

But since you said it's for SVCD, you'd probably best leave it alone and encode it as interlaced.

[segfault]

@manono
Thanks for the tip... I'll try that one today. I thought about just encoding interlaced, but I really need to save that 20% bitrate if I can.

I'll see if I can find someplace to upload a sample to.

[manono]

Hi-

I was thinking later. I agree with you that it's always a good idea to encode as few frames as possible. Decimate(6).Decimate(19), if, indeed, that does it for you, gives you 23.661fps, if your source is 29.97fps. You could also stick AssumeFPS(23.976) in there at the end, adjust the audio, and then run pulldown on it when done. That way you'll get a better quality progressive SVCD.

[segfault]

I've found a host for a sample.

http://home.comcast.net/~aburns2004/decomb_sample.avi

This is a HuffyUV sample resized down from 480x480 to 352x480 for space reasons.

decimate(cycle=6).decimate(cycle=19) didn't seem to work properly either, although it looks much smoother than cycle=5.

Any help much apprciated.

[manono]

Hi-

decimate(cycle=6).decimate(cycle=19) didn't seem to work properly either

That's because it's not exactly as you said it was. There's not really enough there to tell what's going on, but, except for one slightly interlaced frame, this works for that short clip:

AssumeTFF()
B=KernelBob(4)
SmartDecimate(24,58,B,Tel=0.99)

I don't know if it'll work for the whole thing. I haven't found any Telecide-Decimate combinations yet that'll work on it.

[scharfis_brain]

I don't know what to claim about on this clip ?!?

loadplugin("c:\x\decomb510.dll")
avisource("sample.avi").assumetff.assumefps(29.97)
telecide(order=1,post=0)
decimate(5)

works very good without jerks and combs
exept of the one combed frame (44) that occured due to a dropped frame.

edit2: Instead of the usual NTSC 3:2, the pattern is
pppiipppiipppiippii
The 3:2 pattern runs 3 times, but then there's a 2:2 pattern on the 4th time through. this is cause due to framedrops!


edit1: hehe that order=parameter IS important

either use:
assumetff AND order = 1
or:
order = 0

[manono]

Darn, I had to modify my previous script, as I got a dropped frame.

this is cause due to framedrops!

So you're saying scharfi, that the frame drops occured before broadcast, during the telecine process? Because segfault said there weren't any during the capture. But it is strange that the original capture is at 29.976fps. But Decimate(5) leaves dropped frames. There's an obvious one just before the cat hits the ground. There's an orphaned field there that Decomb doesn't pick up on, whereas SmartDecimate does. SmartDecimate(24,58) works, but so does SmartDecimate(25,60). I think the second one is the way to go for the whole video, because it seems to me that it was converted from PAL to NTSC in a very strange way. But, again, there's not much there to work with.

[scharfis_brain]

let me define this kind of 'dropped frame' as skipped frame

this seem to occur very often during the capturing process. but the capturing-app doesn't seem to recognise this.
It is like the Capturecard is already producing this skipped frame.
I also have seen inserted frames.

examples:
all frames A to J are sequencial with individual content and are build out of two fields


typically dropped frame sequence:
A B C C E F G H I J <- frame D has been dropped and replaced by C

skipped frame sequence:
A B C E F G H I J <- frame d is cutted out of the stream

inserted frame sequence:
A B C D D E F G H I J <- frame D is duplicated.


I think, that frame 44 of that stream is just a skipped frame containing the content of the lonely field.

this is my opinion of this short stream.

We definately need a longer one.

I think interlaced MPEG-2 @ 5 mbps would be okay...

[segfault]

All I can say is that I was capturing from S-video input with VDubMod, which reported 0 dropped frames after an hour of capturing. I also captured an episode of Shazam 30 minutes after this one, and it has a perfect 3:2 pattern all the way through. I've already IVTC'd it and encoded my SVCD, and it looks great.

I capture from this source (TVLand) all the time, and this is the only show I've seen this pattern on. I'm not saying that scharfis_brain is wrong, but if that were the case, wouldn't it happen on all my captures?

[scharfis_brain]

okay. If this is the only thing, I'll trust that your capturing is drop-free.

But maybe those old shows had been digitsed by the broadcaster in a bad way which caused those frame-skips.

I do now agree to manono's solution.

[Mug Funky]

i've seen TV broadcasters drop frames on playback before... happens all the time in Australia (channel 9 had been quite bad recently, to say nothing of the noise introduced when they nearest-neighbor HD down to peasant size). we also get a lot of clicks and pops in the audio which is annoying, as well as the odd row of b0rked macroblocks

it is very possible that the problems lie with the broadcaster.

[segfault]

I have uploaded a longer clip that should hopefully provide more insight. MPEG-2, interlaced, 352x480. I'll try the smartdecimate route tonight and see how it works. Thanks for all the help.

http://home.comcast.net/~aburns2004/capture.m2v

I had to delete the other one due to space constraints....

[mj0012]

I've heard that TVLand sometimes increases the playback speed of some of their older shows (Leave It to Beaver was the example I heard) so that they can run the uncut episode but still have more time for commercials. That could possibly account for a weird combing pattern.

[scharfis_brain]

okay, I've examined that sample using telecide(order=1,post=0)

I've searched for dupes of the NTSC-Telecine.

the result:

Frames: 2 7 12 7 | *21* 26 31 36 41 46 | 50 55 60 65 70 | 74 ... 99 | 103 ... 118 | *122* ... 142 |

every | marks a dropped frame between the neighboring dupes
this causes a pattern offset every 25 frames
*x* this frame is itself affected by dropping. It contains an orphan field.

I think, that smartdecimate will be the way to go, because it is able to catch the lonely field...

but you WILL get a jerk every 4/5 second (every 24 frames) due to the dropped frames. You cannot do anything against this.

[scharfis_brain]

got another sample of a 70ies series.

look at this: http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=3507#3507

solution with those old things:

smartdecimate(1250,2997)