1080p Deinterlacing (Luma & Chroma Field Swapped)

[thecoreyburton]

I have a clip I'm trying to deinterlace, taken from iTunes as a 1080p source. The whole season is progressive at 23.976 except for this one episode. I've been trying to work out what the issue is and as far as I can tell, if the animation is at 24fps then there's no interlacing - if it's at 12fps (eg, every frame is doubled) then it's interlaced.

I did a few tests and from what I can tell, if I match the fields using TFM, the chroma lags behind on the interlaced frames by one, it seems.

If instead I bob the clip, it looks like the chroma is one frame ahead. On the following frame it swaps, the luma moves to where the chroma was previously and the chroma moves back to where the luma was previously, effectively making the chroma one frame behind.

I attempted QTGMC in conjuction with SRestore but got similar results, I was thinking perhaps a separate field match for luma and chroma might help but I'm not skill enough to orchestrate something like that myself.

The entire episode is like this and is consistent with this sample provided. (http://www.mediafire.com/watch/ln1gb5icj1hrk4r/sample.avi) Is this a particular form of interlacing that has a name? and does anyone have a good idea on getting around it?

[ChiDragon]

I would recommend reporting the issue to iTunes. I hear they occasionally fix their stupid QC failures. Interlacing is an obvious-enough problem that even your average granny with decent eyesight can notice there's something wrong.

The chroma error is what always happens when interlaced content is encoded as 4:2:0 in progressive mode. The chroma on the interlaced frames is blended together by the 1/2 vertical downsample. The same thing would happen if you took a full interlaced image and resized it vertically to half its original height. 4:2:0 has a separate variant that must be used to correctly handle the vertical resampling for interlaced material. (This is why specific "Convert" functions in Avisynth have the interlaced flag.)

You can see the problem like so:
FFVideoSource("sample.avi")

UtoY() # View "U" channel of chroma in isolation

What you're seeing with Bob enabled is iTunes' IVTC failure. The wrong fields have been matched, so the field order is effectively wrong on those frames and the luma stutters forwards-backwards-forwards. The first pair of "12fps mouth-flap fields" (if you will) don't stutter, the second pair do, the third pair don't, and then the rest of this sample does. If you look at TFM with display=true you'll see that while the two good pairs are using "p" matches, the rest of the matches are being forced to use "n" (opposite-order) matches. Also, if you use a mode number lower than 4, two frames are deinterlaced rather than field-matched.

FFVideoSource("sample.avi")

TFM(mode=4,mChroma=true,PP=0,display=true) # Chroma is still bad

If the IVTC errors are truly only on the 12fps portions throughout, you could simply replace every interlaced frame with the previous frame rather than field-matching it and its attendant corrupted chroma.

TL;DR: Use this...
FFVideoSource("sample.avi")

ConditionalFilter(last,last.Trim(1,0),last,"IsCombedTIVTC","=","true")

You may need to adjust the parameters of IsCombedTIVTC (http://avisynth.org.ru/docs/english/externalfilters/tivtc_iscombedtivtc.htm) to catch stray interlacing in scenes with less movement, or to avoid duping frames in scenes with content that "appears" to be interlacing to the filter but isn't.

[thecoreyburton]

Ah, I was worried that it'd be the colorspace but figured because I've come across other 4:2:0 content that's interlaced which didn't have the problem it couldn't have been that. I didn't know the interlacing flag had such an effect on the handling, thank you. The extra details your provided were very helpful.

I'll see how it goes, I might manually scan through the source and see if the combing occurs in places that aren't at the 12fps portions and hopefully (fingers crossed) I'll just have to apply the last script or a variation of it.

[Music Fan]

The chroma error is what always happens when interlaced content is encoded as 4:2:0 in progressive mode.
Do you mean when there is no de-interlacing ?

[colours]

Do you mean when there is no de-interlacing ?

No amount of deinterlacing wizardry can restore blended chroma.

[Music Fan]

Ok, but it does not answer my question.

[ChiDragon]

When I said "interlaced content is encoded" I meant it literally. So yes, no deinterlacing prior.

[Music Fan]

Ok, that's what I had understood but was not sure you meant this.
Does this chroma error appear because the decoder believes the video is progressive while it's interlaced ? If yes, I guess a simple interlaced re-encoding can solve the problem (nothing is lost or created).

edit : I downloaded the video, the problem seems more complex than just a bad interpretation because of a missing interlaced flag which can't create this swapping [clearly visible when using separatefields() ], correct me if I'm wrong.

[ChiDragon]

Does this chroma error appear because the decoder believes the video is progressive while it's interlaced ? If yes, I guess a simple interlaced re-encoding can solve the problem (nothing is lost or created).
No, the error is on the encoder side. The decoder is correctly interpreting the data it's been presented. Forcing it to use interlaced mode would only add additional CUE (http://avisynth.nl/index.php/Sampling).

It would be:
interlaced falsely downsampled using progressive (causing blending)
+
(blended) progressive falsely upsampled using interlaced (causing alternating colorless lines on saturated edges)

the problem seems more complex than just a bad interpretation because of a missing interlaced flag which can't create this swapping [clearly visible when using separatefields() ], correct me if I'm wrong.
Assuming we're talking about the same effect, the reversed fields were caused by iTunes' incorrect IVTC (the video is 23.976, not 29.97). But I already mentioned that before, so maybe you're referring to something else.

[Music Fan]

Thanks. I wasn't talking about anything else, I was focused on your explanation about chroma error (believing you meant it explained the swapping) and I forgot the other part of your message.
To avoid confusion, I rephrase my question : when one has interlaced video (50i for example) and forget to tell the encoder it's interlaced (thus considered as 25p), what happens ? And how to solve artifacts if there is any ?

[thecoreyburton]

ChiDragon, I did a run through with your script and it worked almost perfectly. It wasn't sensitive enough to pick up all the combed frames as you predicted, so how do I tweak the parameters of a conditional filter? I haven't had the opportunity to use one before so I'm not sure where I'd input the parameters. Thank you all for your help!
FFVideoSource("sample.avi")
ConditionalFilter(last,last.Trim(1,0),last,"IsCombedTIVTC","=","true")