Interlacing Sporadically Occurring?

[Unagi]

Hello, I'm using a USB capture device via VirtualDub to capture 480i video sources through an S-Video cable.

A proper capture would show interlacing/combing throughout (or at least where there's motion), right? Instead, I'm mostly getting footage with little to no combing; does this mean that it's automatically dropping fields or something? I thought that generally only occurred in the software that's bundled with these devices... or can there be something built into the driver (or somesuch) of the capture device itself that compels it to do on-the-fly deinterlacing?

What's even more confusing is that the device seems to change whether it's doing (what may be) this deinterlacing or not in the middle of a video capture! One scene will have combing, the next, none. This tends to occur when a screen fades to black, but isn't definite.

Is this something normal? Is there a way to make it behave before capture? If not... is there a way to fix it after capture? (So as to not run deinterlacing algorithms over frames that don't need it.)
-------------

If it matters any, I noticed this first in video captures, but then went to see if I could replicate them in the preview window of VirtualDub using overlay. The issue was still present, so I'm thinking it isn't the way I'm capturing it?

Thanks for any pointers and all help!

[lordsmurf]

480i video sources

What is the source?

[jagabo]

It's not common with NTSC broadcast but 480i video can contain progressive frames encoded and transmitted interlaced. You won't see any comb lines with that. On the other hand, some capture devices do deinterlace while capturing. Especially those that encode with MPEG 4 (Divx/Xvid).

[vhelp]

I thought that generally only occurred in the software that's bundled with these devices...

are you sure you are using virtualdub, or the bundled softare you mentioned ? otherwise..

what is the resolution on the capture window you are using ? ..if its less than 240 pixels in height the cap card could be throwing away one field giving u back a progressive video, or..

post a small (30mb or less) representative sample you captured or pass it through mediainfo and post the results--should tell us right away what the problem is if any.

-vhelp 5475

[Unagi]

What is the source?

The sources I was originally mystified about were from various GameCube games. I had just received this capture device and wanted to test it out under controlled (har) conditions, though, I suppose capturing a DVD would have served just as well in that sense.

It's not common with NTSC broadcast but 480i video can contain progressive frames encoded and transmitted interlaced. You won't see any comb lines with that. On the other hand, some capture devices do deinterlace while capturing. Especially those that encode with MPEG 4 (Divx/Xvid).

Maybe that's what's happening below?

I went ahead and plugged it into another television during the football game today, and observed that the interlacing/combing was present in every frame, during the game at least. The commercials appeared to be... telecined ? 3 non-interlaced to 2 interlaced frames. I thought that was mostly for movie footage, though? This was even in a McDonald's commercial! In one commercial, with Fox's stars tossing a football from one set to another, the live action appeared to be telecined while the full-screen signage ("TV's Biggest Shows" "Are Back") was interlaced in every frame. The latter was edited in later, so I can see why there may be differences (though I thought television was generally interlaced entirely?). Also, one commercial, was telecined with blurring rather than the comb artifacts.

Perhaps I'm missing out on some fundamental understanding here... though I'm not an absolute newbie to interlacing and the like. The football game did appear to be interlaced in every frame, however. So, nothing up there appears to be "random" though I am still confused as to exactly what is happening.

--------
vhelp: I'm using VirtualDub and am capturing at full height (480). I did go and switch on a N64 I had hooked up to this television to see if I can replicate "random" interlacing. I've attached a portion from the recording to this post [no audio, composite cable], and following is what I observed on a frame-by-frame analysis:


Frame #s
0-68 - no combing (Loading?)
69-264 - combing (non-player control)
265- 311 - intermittent combing (extra elements on screen?)
312- 844 - no combing
845-1093 - combing (hit wall? Big screen in background?)


Are game consoles another beast entirely? Why doesn't the interlacing stay consistent? Does it have to do with the frame rate? I'm more than a bit confused, here.

----
And I'm sure I didn't encode it in the best way possible, 4000 kbps is overload for Xvid, for one - my apologies. Which brings me to another question... what does ticking "interlaced" under compression settings do for Xvid and other codecs? I didn't observe any changes to the output video when I tried it out [I left it unticked for this recording].

[lordsmurf]

Video games are progressive over interlace.

[jagabo]

What travels over an s-video cable is always interlaced video -- one field at a time, alternating top and bottom fields, 59.94 fields per second. Those fields can each come from a different picture (59.94 different half-pictures per second) or they can be pulled down from progressive frames.

It's hard to say exactly how this is happening but I suspect the console is trying to generate 29.97 fps (using 2:2 pulldown to create 59.94 fields per second), but sometimes falls back to 23.976 fps (using 3:2 pulldown to create 59.94 fields per second). Since your capture card is pairing fields together into frames, sometimes you get two fields from the same game frame (they look progressive), sometimes from two different game frames (they look interlaced).

On top of that, your Xvid AVI is encoded progressively so the colors of the two fields are blurred together.

[Unagi]

Progressive over interlace? Okay, I suppose that makes sense.

So, I'm guessing with television/cable capture that will be displayed on a progressive computer monitor, I should determine what kind of interlacing is going on (telecine/interlaced/mixed) before applying a deinterlacing algorithm. It appears pretty consistent so that shouldn't be too difficult (is there a program/script that determines this? How do you deinterlace mixed kinds?).

..and with games it's more "anything goes"? Or would a mixed identifier/deinterlacer take care of this? I'd rather not "hurt" non-interlaced frames if I don't have to.


Sorry for all the questions, I just didn't realise interlacing could be so variable. I thought it simply was interlaced every frame if you were capturing from a non-HD source. The goal I'm trying to achieve here is recording VCR/TV/Game footage (all through composite or S-video) and viewing it on a computer monitor with proper care taken for the interlacing.

Should I be sure to tick the "interlaced encoding" on a compression codec, then? What does this do exactly other than set a flag in the metadata (I didn't notice much else..)? If I don't want to capture in a space-guzzling codec like Huffyuv/lagarith/MJPEG what's a good alternative? And any pointers on what to do with deinterlacing would be much appreciated!

Many thanks.

[lordsmurf]

Interlaced frame encoding isn't necessarily going to have comb lines, if the source is progressive pushed out across interlaced method. So you're looking for something that isn't there, and doesn't have to be.

Good deinterlacers understand what's what.

[Unagi]

Okay, I think I understand. I mostly go for yadif since it's fast and said to be better than most other fast ones. Does that refrain from processing progressive frames? Should I just simply run a deinterlacer like that over footage that is "randomly interlaced"? Or do I need to run some kinda scan first?

(And what does "Interlace Encode" on a compression codec do? Is it just a flag for metadata? Should it be ticked for cable footage? Game Footage?)

[jagabo]

Okay, I think I understand. I mostly go for yadif since it's fast and said to be better than most other fast ones. Does that refrain from processing progressive frames?

Not really. It tries not to but it does make mistakes.

Should I just simply run a deinterlacer like that over footage that is "randomly interlaced"? Or do I need to run some kinda scan first?

Only if you need progressive frames (like when uploading to Youtube).

(And what does "Interlace Encode" on a compression codec do? Is it just a flag for metadata? Should it be ticked for cable footage? Game Footage?)

Basically, it splits the two fields into separate images and encodes them separately to keep from co-mingling the chroma channels of the two fields. Upon decompression it restores the interlaced frame.

If you encode the interlaced frame as if it is progressive, as you did in your sample, you get artifacts like this when you deinterlace (simple bob here):



Notice how the red color of the cart has blended into the dirt ahead of it (where the cart is in the next field).

Encoding a progressive frame as if it is interlaced results in much more subtle blurring of the chroma channels.

[Unagi]

Oh... that makes a lot of sense and now I see why I've been seeing artifacts like that from time to time! For some goofy reason I was thinking that the file size would be larger under an interlaced encode or I'd see some difference in playback/visual analysis. But since fields are half the size as any given frame, an interlaced encode of two fields (at half the size) per frame would be about the same size as a progressively encoded frame at the full height per frame! And as you say, the video decoder outputs it correctly so I wouldn't notice anything during a simple once-over.

Thanks for that, it's been bugging me. I managed to overlook what was right in front of my nose.


All my footage is intended for view on a computer screen, so I'm going to have to take a look into deinterlacing schemes. Running it over actual interlaced footage (in every frame) is simple enough, but I'm still a little hung up over mixed signals like game footage. I suppose I can get away with just running a deinterlace as with any other interlaced footage, right? Or should I scan it (and how?) to tell the deinterlacer where to work?


Many thanks for all the explanations and sharing of insight! I feel much better informed now.

[jagabo]

AviSynth's TFM() worked well with your sample video. It would have worked better if the sample hadn't been compressed with Xvid in progressive mode.