Question about Interlaced / Progressive.

[monzie]

Maybe US TV's are just shite, eh?

Most UK/Ire/Scan/Euro DVD's are prog and no-one cares....the picture on the TV is still great...the only ones WHO EVER whinge about video files (avi's or DVD's) are you US kiddies....try BUYING some decent TV kit..instead of shite!.....4:3 Tv;s..pan/scan,,,,WHAT does it all mean (other than shite?)

[celtic_druid]

Well the difference is that the one that was encoded as interlaced can be de-interlaced or re-encoded as interlaced and yes field order does matter.

[edDV]

Maybe US TV's are just shite, eh?

Most UK/Ire/Scan/Euro DVD's are prog and no-one cares....the picture on the TV is still great...the only ones WHO EVER whinge about video files (avi's or DVD's) are you US kiddies....try BUYING some decent TV kit..instead of shite!.....4:3 Tv;s..pan/scan,,,,WHAT does it all mean (other than shite?)

You are missing the point. Ignoring progressive TV playback and film ITVC for now, lets focus on the basics.

Quality 24 fps progressive sources on commercial DVD get played out as interlace PAL or interlace NTSC to the analog outputs (composite, S-video, or interlaced component analog).

PAL gets played directly at 25 fps (50 fields per second), NTSC goes through the 2:3 field repeat process to play at 29.97 fps (59.94 fields per second)

An interlace PAL DVD (different animal) has 25 fps (50 fields per second) video stored directly on the DVD for direct playback.

An interlace NTSC DVD (yet another animal) has 29.97 fps (59.94 fields per second) video stored directly on the DVD for direct playback.

The issues being discussed above do not relate to playing back properly mastered commercial DVDs. They are talking about capture of interlaced sources for recording to interlaced PAL or NTSC DVDR.

The correct way to do this is to capture, edit, encode and author the DVD interlaced throughout. That way the same video is recorded and played back the same way it would be on another recording device.

Some capture-editing-encoding processes deinterlace the video to 25fps PAL or 29.97fps NTSC. Sometimes this is beneficial for extreme compression, streaming applications or optimizing for computer display, but it seriously degrades the video for interlace DVD playback to an intelaced TV. Deinterlacers available to home PC users are highly destructive and should be avoided if your target is an interlaced TV set. MPeg4 based recording codecs often force a deinterlace and therefore are highly destructive. Understand the compromises of your codec.

Keep in mind I'm ignoring film based sources* for this analysis. We are talking about video in and video playback.


* Material that originated on film might be capable of conversion back to ~24fps progressive frames by reordering and combining fields. In PAL this is easy. The fields are simply weaved into a progressive frame. For NTSC, the field repeat process needs to be reversed (aka IVTC) before the weave can take place. This only works for pure film sources.

[junkmalle]

Well the difference is that the one that was encoded as interlaced can be de-interlaced or re-encoded as interlaced and yes field order does matter.

I recommend you try it. You're in for a surprise.

Interlace is not a matter of how an image is encoded it's the contents of the image. Yes, it helps if the encoder knows an image is interlaced. It can use a different DCT array to prevent bleeding of the two fields, it can pack the image differently, etc. But in the end, the job of the codec is to output an image that looks as close as possible to the source.

So an interlaced source is still interlaced after it's been through an encode/decode cycle and the field order hasn't changed. Even if the codec handled it internally as progressive. If the encoder incorrectly compressed an interlaced video as progressive the final output might not be as good as it could have been. But it's still interlaced. And vice versa.

[celtic_druid]

So you are telling me that if I compress an interlaced source with x264 (a codec that doesn't support interlaced) then the output will be the same as the source(x264 does have a lossless mode)?

[junkmalle]

So you are telling me that if I compress an interlaced source with x264 (a codec that doesn't support interlaced) then the output will be the same as the source(x264 does have a lossless mode)?

If the codec is lossless you certainly can treat the output as interlaced. I took a short interlaced capture from digital cable, converted it to x.264 in single pass Quantization mode with a Q of 0, then IVTC both the X264 output and the original video with VirtualDub mod. The results were the same.

Here's one of the two interlaced frames from which the the image was reconstructed (IVTC):



Here's the reconstructed image from the X264 file (the frame from the original MPEG IVTC looked identical):



In a program like TMPGEnc you can tell the program to treat the "progressive" X264 file as if it's interlaced and which field order it is:



From then on the program will handle it just as well as the original interlaced source.

Even with a lossy compression, as long as there isn't too much bleeding between the two fields, you can treat the "progressive" encoding as if it's interlaced.

Here's the same sample with an intermediate X264 compression at Q=30 and IVTC:



With that high a compression in X264 there is obvious damage done to the two fields so IVTC didn't work as well.

Think of it like this: The uncompressed RGB "codec" don't have an interlaced/progressive setting. The picture that comes out is exactly the same as the picture that went it. If the picture was interlaced it comes out interlaced; if the picture was progressive it comes out progressive. If another codec is lossless (or reasonably close) it's no different. You can treat the output as interlaced if the input was interlaced. It doesn't matter how the codec handled the images internally. Or if the codec "tells" you whether the output is interlaced or progressive.

[celtic_druid]

Yeah, it did occur to me after posting that lossless was a bad example.

[Wilbert]

Interlace is not a matter of how an image is encoded it's the contents of the image.

It's a bit more complicated than this. This is indeed the case for YUY2 and RGB stuff. But for YV12 stuff it's not.

To be less cryptic. There is a difference between encoding progressive content (say 25 fps) as interlaced or as progressive IF the video is stored as YV12. The reason is that two neighbouring horizontal lines share their chroma (for progressive two neighbouring horizontal lines in a frame, and for interlaced in a field). So, celtic is correct.

[dphirschler]

The danger is encoding it progressive (if the source is interlaced) is getting the field order wrong. The display will still only display one field at a time, but wrong field order will show serious stuttering.


Darryl

[Wilbert]

The danger is encoding it progressive (if the source is interlaced) is getting the field order wrong.

Ok, but at least that's fixable.

Another problem will be the Chroma Upsampling Error (which is related to my remark above). I suggest you have a look at http://www.avisynth.org/Sampling

[junkmalle]

The danger is encoding it progressive (if the source is interlaced) is getting the field order wrong.

Ok, but at least that's fixable.

So what your're saying is, even if a program tells you a video is progressive, or the video is compressed with a codec that you know doesn't support interlacing, you might be able to treat the video as if it's interlaced and get a better result when watching on TV than if you treated it as progressive. Fascinating! Sounds familiar too...

[Wilbert]

So what your're saying is, even if a program tells you a video is progressive, or the video is compressed with a codec that you know doesn't support interlacing, you might be able to treat the video as if it's interlaced and get a better result when watching on TV than if you treated it as progressive.

I'm not sure why you think that i think this, because i was not saying this above. Besides, i disagree with it:

If you have progressive contents i would create progressive MPEG-2 out of it, even if you are going to watch it on TV. The reason is not that the quality would be better (i don't think you will see any difference on tv), but if you are going to view it on a progressive display the quality will be better.

edit: corrected post

[junkmalle]

So what your're saying is, even if a program tells you a video is progressive, or the video is compressed with a codec that you know doesn't support interlacing, you might be able to treat the video as if it's interlaced and get a better result when watching on TV than if you treated it as progressive.

I'm not sure why you think that i think this, because i was not saying this above. Besides, i disagree with it:

If you have progressive contents i would create progressive MPEG-2 out of it, even if you are going to watch it on TV. The reason is not that the quality would be better (i don't think you will see any difference on tv), but if you are going to view it on a progressive display the quality will be better.

edit: corrected post

The original poster asked how he could tell if a video was progressive or interlaced. I said he had to look at it himself because software sometimes gets it wrong.

I later pointed out that an interlaced video, when opened in a program that didn't recognise the video as interlaced, can still be treated as interlaced (assuming the program lets you specify this yourself). It might have some field contamination problems (as in your YV12 example) but the field order remains important.

[Wilbert]

The original poster asked how he could tell if a video was progressive or interlaced. I said he had to look at it himself because software sometimes gets it wrong.

Well, that's true, but .... If you want to know whether the clip has combing (imo that's what's important in practice), just looking at it will do. But if the clip doesn't show combing it doesn't imply it's progressive. Think about progressive contents encoded as interlaced YV12 (it doesn't show combing but it's interlaced). If you look only at the chroma (by subtracting the luma) you will be able to see that.

I later pointed out that an interlaced video, when opened in a program that didn't recognise the video as interlaced, can still be treated as interlaced (assuming the program lets you specify this yourself).

This is not what i wrote or implied above, because it's false.

Of course you can always encode something (being progressive or interlaced) as interlaced. The problem is that in your example the video will be messed up.

In your example above, suppose you start with interlaced video (which shows combing), encode that as progressive (x264 for example) and reencode it to interlaced MPEG-2 for your TV [at least i think that's what you mean in your example, but i'm not sure since you use nonstandard terminology]. The only problem is that your reencoding will be borked. The chroma of different time instants will be averaged, leading to this 'chroma upsampling error'.

[junkmalle]

In your example above, suppose you start with interlaced video (which shows combing), encode that as progressive (x264 for example) and reencode it to interlaced MPEG-2 for your TV [at least i think that's what you mean in your example, but i'm not sure since you use nonstandard terminology]. The only problem is that your reencoding will be borked. The chroma of different time instants will be averaged, leading to this 'chroma upsampling error'.

Of course the chroma will be borked. I'm not recommending that people do that as a normal procedure. I'm saying you sometimes come across a video that has been incorrectly encoded this way and there's no way to get the original source. If you simply ignore the fact that the video was interlaced to start with (ie, it has obvious comb lines) you may end up adding to the problem by encoding to DVD with the wrong field order. The result of course is jerky/strobey playback on TV.