New to AVISynth and need some help understanding colour conversions & "interlaced"

[FlimsyFeet]

I'm getting confused here and the more I read the more confused I get, especially with regard to what "interlaced" means. I could do with someone explaining things simply so that my poor brain can take it in.

OK let's say I'm capturing analogue PAL sources, VHS or laserdisc, which are originally from film (progressive). But I'm capturing as "interlaced" because the field threshold in huffyuv is 288 lines and I'm capturing 576, correct? Or should I change this threshold?

Wilbert once told me this is why you shouldn't use the VBLE codec for capture, as the capture card delivers YUY2 but VBLE downsamples to YV12 assuming progressive video, and even though there is no combing or interlacing artefacts in the raw capture it is in fact still "interlaced".

Also AVISynth converts the huffyuv YUY2 file to YV12 when the file is opened. It looks like progressive frames, but is it still interlaced now? And what if I want to use the pixiedust denoiser, I need to convert back to YUY2 first, but should I use the "interlaced=true" parameter in the ConvertToYUY2 command? Would it be better to use an older version of AVS that works in YUY2 anyway? And do I need to do anything to make the video progressive so that the denoiser looks at the whole frame and not just each field separately, or does it assume that anyway?

Help!? :D

[Wilbert]

But I'm capturing as "interlaced" because the field threshold in huffyuv is 288 lines and I'm capturing 576, correct? Or should I change this threshold?
No, that's ok. Btw, I'm not sure what happens if you choose a lower threshold. I guess you can find that somewhere on this forum :)

Wilbert once told me this is why you shouldn't use the VBLE codec for capture, as the capture card delivers YUY2 but VBLE downsamples to YV12 assuming progressive video, and even though there is no combing or interlacing artefacts in the raw capture it is in fact still "interlaced".
If there's no combing it is progressive (at least for YUY2/RGB streams). So, if you know your cap has no combing you can use VBLE. Apologies if I ever implied otherwise :)

Also AVISynth converts the huffyuv YUY2 file to YV12 when the file is opened.
I'm quite sure it doesn't. But you can easily check that with "avisource().info". The reason is that huffyuv can't deliver YV12.

And what if I want to use the pixiedust denoiser, I need to convert back to YUY2 first, but should I use the "interlaced=true" parameter in the ConvertToYUY2 command?
If there is no combing you should use interlaced=false.

And do I need to do anything to make the video progressive so that the denoiser looks at the whole frame and not just each field separately, or does it assume that anyway?
Most denoisers require a progressive stream (unless it has an interlaced option somewhere or it is stated in the docs :)). So IF your video has combing you should either deinterlace first or use this SepFields/Even/Odd/denoise/Weave stuff.

[FlimsyFeet]

Originally posted by Wilbert
No, that's ok. Btw, I'm not sure what happens if you choose a lower threshold. I guess you can find that somewhere on this forum :)
Actually what I meant was should I make this threshold higher, i.e. 576, if I know that I am capturing something that is film-based?
Originally posted by Wilbert
If there's no combing it is progressive (at least for YUY2/RGB streams). So when does it become progressive again? The original film was telecined (for PAL is it "2:2 pulldown"?) to an interlaced video signal, which is what is output by a VCR, huffyuv is capturing separate fields, but when the capture file is opened say in VirtualDub each frame shows both fields combined together with no combing artefacts.

What I used to do for my VHS caps, before I started learning AVISynth, was use the "Deinterlace PAL movie" filter plugin with VDub, which didn't actually change anything but I assumed it converted it to progressive, then run some VDub smoothing filters, then frameserve to CCE and encode as "progressive". Was the deinterlacing step actually required at all?

[Wilbert]

Actually what I meant was should I make this threshold higher, i.e. 576, if I know that I am capturing something that is film-based?
Don't know. I will ask around.

So when does it become progressive again? The original film was telecined (for PAL is it "2:2 pulldown"?) to an interlaced video signal, which is what is output by a VCR, huffyuv is capturing separate fields, but when the capture file is opened say in VirtualDub each frame shows both fields combined together with no combing artefacts.
IF you have a pal 2:2 pulldown signal (coming from film 24 fps), it means that some fields are mixed (which people call progressive, not interlaced ). Which you can convert to a progressive stream with Telecide. When doing that it will have a duplicate frame (, which can be dropped using decimate IF you want to convert it back to 24 fps).

remember with an interlaced stream fields are coming from different time instants, which is not the case here.

was use the "Deinterlace PAL movie" filter plugin with VDub, which didn't actually change anything but I assumed it converted it to progressive,
It seems to me, if it doesn't change anything it doesn't change anything ??? No need to use it then :)

"Deinterlace PAL movie" (...) Was the deinterlacing step actually required at
This plugin is called a deinterlacer, but it doesn't really deinterlace streams. It's doing a IVTC on a pal stream (ie phase shift by one field or something like that). If your cap doesn't show frames with "mixed" fields then you don't need this.

btw, have a look at the analog capture guide: 7.1.3 -> pal -> option 1

I hope it's clear now :)

[Arachnotron]

AFAIK, the threshold setting in huffyuv simply gives the number of lines above which huffy assumes the video is interlaced.

So if your treshhold is set to 288 but you are capping 576 huffyhuf will treat it as interlaced. This is why 288 is a safe value: if you cap either 240(ntsc) or 288(pal) horizontal, huffy assumes non-interlaced.
Capping either 480 or 576 lines, huffy would assume interlaced video.

So for most real-world capping you can leave it at 288, even for NTSC. The treshold only becomes important when you are capping at non-standard horizontal resolutions (which you should never do anyway)