Dealing with b0rked telecine

[Yuri Khan]

I’ve got a source with a peculilar telecine. I will try to describe it, maybe someone knows what to do with it.

A traditional telecine has a rigid pattern of two interlaced frames, three progressive, going like this in a loop. A bad telecine changes the phase at some points but keeps the period of five frames. And if a frame is interlaced, then both luma and chroma are interlaced.

My source (a stack of DVDs), in addition to normal interlaced and progressive frames, also has frames where luma is progressive but chroma is interlaced.

The IVTC filters I tried all handle the interlaced frames more or less, but when it comes to mixed frames, the interlace in the chroma channels remains.

I’ve tried separating channels and deinterlacing each channel separately. Then chroma sometimes lags one frame behind luma.

I have uploaded a short sample here (http://centaur.gorodok.net/b0rked-telecine-huffyuv.avi) (lossless Huffyuv (http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html), 10 frames, 2.5MB). The mixed frames are: 4, 5, 8, 9 (watch the mouth).

So, does anybody know of an existing filter that can IVTC such sources, or have any ideas how it can be done? Thanks in advance.

[neuron2]

Your file is borked too. I can download only 3MBytes of it.

[Yuri Khan]

Why, so it is. “Hurry too much, make people laugh.” Reduced the clip so that it fits in 3M and still shows both kinds of interlace.

[scharfis_brain]

please do not provide recompressed videos. the original VOB or MPG will be better.

[Elic]

Yuri Khan
Your clip looks like luma and chroma is telecined separately and with differtent phase, and/or video was converted from YV12 to YUY2 with wrong interlace flag.

Maybe neuron2's telecide(order=1,guide=1).Decimate() is able to nearly repair it. In any case, I hope that script will help you analyze and repair your video:function showfields( clip c, string sub ) {
c
assumetff()
separatefields()
stackvertical( selecteven().subtitle( sub + " top" ), \
selectodd().subtitle( sub + " bottom" ) )
}
AVISource( "b0rked-telecine-huffyuv.avi" )
#converttoyv12( interlaced = true ).converttoyuy2( interlaced = false ) #for experiments
#info()
# Telecide(order=1,guide=1).Decimate() # - may
s = last

u = s.utoy()
v = s.vtoy()
stackhorizontal( u.showfields( "U" ), v.showfields( "V" ), s.subtitle( "source" ) )

[Yuri Khan]

please do not provide recompressed videos. the original VOB or MPG will be better.
Oh, of course it will. Unfortunately I am unable to host a gigabyte file and I’m sure there wouldn’t be many people willing to download it.


Anyway, I think I’ve nailed the root cause of the problem.

As I came to understand, there are two types of telecine: hard telecine, when fields are interlaced in the video stream on DVD; and soft telecine, when video data is progressive but there are flags that cause the decoder to duplicate fields in a telecine pattern. All DVDs I ripped before had either hard telecine, with a nice 3:2 pattern, or soft telecine over progressive video, again giving a nice 3:2 pattern.

Also as I learned, to determine the type of telecine, one enables the Ignore Pulldown Flags mode in DGIndex. So I did that and examined the resulting project.

What I see there is mostly progressive video, but every once in a while there is a single interlaced frame. The sequence from which the above clip was cut is presented in the left half of the following scheme. And the TFF/RFF flags are in the right half.
4691: PPPP PPPP 3123 0012
4699: PPPI PPIP 3130 1300
4707: PPPP PPPI 0013 0130
4715: PPIP PPPP 1301 3130
4723: PPIP PPPP 1300 1231
4731: IPPI PPPP 2312 3131
4739: PPPI PPIP 2312 3123
4747: PPPP PPIP 1312 3123
4755: PPPP PPPP 1313 0131
4763:
And here’s what DGIndex gives when asked to parse the .d2v file it produced:
…
4699 (B): 5921,5921,5922........3 *
4700 (P): 5922,5923,5923........1
(GOP)
4701 (B): 5924,5924,5925........3
4702 (B): 5925,5926.............0 *
4703 (I): 5926,5927,5927........1 *
4704 (B): 5928,5928,5929........3
4705 (B): 5929,5930.............0 *
4706 (P): 5930,5931.............0
…
So, for example, display frame 5925 is formed by interlacing frames 4701 (progressive) and 4702 (interlaced). I’m not inclined to derive exactly how that is done, but it is clear that nothing good can ever come from it. Same way, interlaced frame 4702 and progressive 4703 are interlaced into display frame 5926.


By manually modifying the .d2v file, I managed to force two interlaced frames to form their own display frames, not interlacing with anything else. In order to automate this process, however, I will have to know which original frames are interlaced and which are not, and that is not going to be trivial… (Yes, I know the .d2v file contains info on which frames are supposed to be interlaced; I checked that this info is not accurate in my case.)

[neuron2]

Yes, I know the .d2v file contains info on which frames are supposed to be interlaced Nope, that's not true. It contains info on how the MPEG picture is encoded; that is not the same as whether the content is actually progressive.

I did AssumeTFF().SeparateFields() on your AVI and it looks like typical field blended crud to me. Do a search on "blended fields". It could also be an instance of the strange chroma ghosting we have seen from time to time. There are threads on that too.

[foxyshadis]

Oh, of course it will. Unfortunately I am unable to host a gigabyte file and I’m sure there wouldn’t be many people willing to download it.
You can use dgindex to clip it. Find the segments you're interested in and use home/end to set the area live vdub, then "save project and demux video" to get just that chunk as m1v/m2v.

[Yuri Khan]

@neuron2
It contains info on how the MPEG picture is encoded; that is not the same as whether the content is actually progressive.Thank you for the correction.
looks like typical field blended crudNo, it’s not blended. In affected frames half the chroma is from the adjacent frames but it’s not blended.

@foxyshadis
Thanks, I didn’t know about this feature.

Here (http://centaur.gorodok.net/b0rked-telecine.demuxed.m2v) is the clip (68 frames, 2.5M) and here (http://centaur.gorodok.net/b0rked-telecine.d2v) is the accompanying d2v. Observe that, when loaded directly into VirtualDubMod, the m2v does not exhibit chroma bleeding; but when used with the d2v, it does (frames 5–6, 16–17).


Now, since I have traced the problem down to pulldown flags, it seems a shame to try to recover correct data after they are corrupted. After all, the best way to do a job is by not having to do it in the first place :)

I succeeded in identifying hard-interlaced frames by feeding the ignore-pulldown-flags d2v through the combination of Telecide(…, post=1, hints=true), KernelDeint(…, debug=true) and DebugView. Well, sort of; with default settings, they tend to err on the paranoid side. But I’ll manage.

After that, it is just a matter of a perl script that magically stirs the pulldown flags in the d2v project, so that each hard-interlaced frame is Top field first but not Repeat first field, while keeping the invariant that next TFF is equal to previous TFF xor previous RFF.


Everybody, thanks for your help :) I learned a lot with this encode.