Correct structure of interlaced frame?

[MGRip]

Hi,

I'm trying to figure out what is the correct binary structure of interlaced video (raw YUV). I have 2 guesses (for instance: 640x360 video, odd first):

1.Each frame is full size (640x360), while both Y and chroma channels are: first line for first field, second for second field, 3rd for first field, 4th for second field and so on...

2.Each frame is full size (640x360), while lines 1-180 are for first field and lines 181-360 are the second field.

What is the correct one?

Thanks.

[LoRd_MuldeR]

In reality there are different memory layouts for "raw" YUV formats. There is not the one.

First off all, planar and packed formats can be distinguished. While the former stores all Y values, all U values and all V values in a large chunk of memory each (Y1, ..., Yn, U1, ..., Un, V1, ..., Vn), the latter stores these values in an "interleaved" way (Y1, U1, V1, ..., Yn, Un, Vn).

Furthermore, interlaced video is an additional "problem". I think what you call method (1) does exist in practice. But it hardly works with the color subsampling that usually is applied to YUV data. Well, YUV 4:2:2 works okay with interlaced video that way, but YUV 4:2:0 obviously doesn't!

That's why, at least for interlaced YUV 4:2:0, there is a special mode where the chroma is subsampled separately for each filed. Somewhat like your method (2).

And then, of course, there is the possibility to have each field of an interlaced video in a separate frame, like SeparateFields() in Avisynth.

The good thing about standards is, there are so many of them to choose from ;)

See also:
* http://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_systems_and_ratios
* http://www.fourcc.org/yuv.php

[Gavino]

Furthermore, interlaced video is an additional "problem". I think what you call method (1) does exist in practice. But it hardly works with the color subsampling that usually is applied to YUV data. Well, YUV 4:2:2 works okay with interlaced video that way, but YUV 4:2:0 obviously doesn't!

That's why, at least for interlaced YUV 4:2:0, there is a special mode where the chroma is subsampled separately for each filed. Somewhat like your method (2).
I think you are mixing up two things here: (a) the chroma subsampling method, and (b) the method of data storage in the frame. As far as I am aware, most formats (including YUV 4:2:0) do use storage method (1) where the fields are stored on alternate lines.

[LoRd_MuldeR]

I think you are mixing up two things here: (a) the chroma subsampling method, and (b) the method of data storage in the frame. As far as I am aware, most formats (including YUV 4:2:0) do use storage method (1) where the fields are stored on alternate lines.

But how exactly is interlaced YUV 4:2:0 handled? :confused:

IMO the subsampling and the memory layout are closely related. YUV 4:2:0 shares chroma samples between 2x2 pixel blocks. If the data was stored for interlaced video in the same way as for progressive, the chroma would be shared between pixels in lines 0 and 1, 2 and 3, 4 and 5, 6 and 7, and so forth. That obviously would result in artifacts, as odd and even lines are from a different time index. So what we need is that chroma is shared between pixels in line 0 and 2, 1 and 3, 4 and 6, 5 and 7, and so forth. I think in a "planar" format this is simply realized in that the first W/2 chroma samples are used for lines 0 and 2, the next W/2 samples are used for lines 1 and 3, and so forth (where W is the width in pixels). Is that correct? And how does it look "packed" then?

[nevcairiel]

Interlaced YUV, 4:2:0, 4:2:2 or 4:4:4, planar or packed, is all just the lines of the two fields interleaved. There is no special behaviour for Chroma when it comes to actually storing the image, which is exactly why the chroma upsampling error exists, because you can't upsample it the same way as progressive, because only every other line belongs to this image, and the lines in between to another image.

In short, the memory layout of YUV looks exactly the same, no matter if progressive or interlaced.
You just need to be careful when upsampling interlaced chrome, because it skips every other line. Not being aware of this does cause the problem called "Chroma Upsampling Error".

[Gavino]

If the data was stored for interlaced video in the same way as for progressive, the chroma would be shared between pixels in lines 0 and 1, 2 and 3, 4 and 5, 6 and 7, and so forth. That obviously would result in artifacts, as odd and even lines are from a different time index.
The data is stored the same way for interlaced and progressive, and therefore must be processed/interpreted differently, depending on whether it is known (or assumed) to be either interlaced or progressive. Failure to do this properly results in the infamous Chroma Upsampling Error (CUE) (http://avisynth.nl/index.php/Sampling#Color_format_conversions_and_the_Chroma_Upsampling_Error).