Chroma sampling (and Cedocida YV12 option)

I'm quite confused (ignorant rather)... Here's what I THINK happens. Correct me if I'm wrong.

NTSC DV
YC Y Y Y
YC Y Y Y
C is the chroma info for pixel 1 only

PAL DV
YV Y YV Y
YU Y YU Y
No U info on line 1, no V info on line 2

MPEG 2
Yc1 Y Yc3 Y
Yc1 Y Yc3 Y
c1/c3 are the average vertical chroma of two consecutive pixels on two lines (2x2 block) ?

I'm guessing that the YV12 MPEG sampling option is needed to quot;copyquot; the chroma info in pixel 1 to pixel 3 in case of NTSC. Else an application would treat it as 4:2:0 and the pixels in col 3 amp; 4 would be displayed without colour ? Or is the chroma info calculated depending on the lines above and below it and assigning some weightage ?

Also can an application differentiate between MPEG2 YV12 and DV YV12 sampling? If not, then DV would be displayed with U info missing in one line and V info missing on the next !

And you need to take into account quot;interlacingquot; as well.  This page has excellent illustrations: DMG/chroma.html

DV Codecs handle all these calculations, in their specific ways.  We have the quot;DV decoder differencequot; and quot;DV decoder difference - updatequot; threads here.

Thanks for that link. Took some time to read through the sampling information in Avisynth documentation and followed all the external links. (But I still don't get the cedocida option.) Also, i don't see a direct YV12-gt;RGB. Is it always YV12-gt;YUY2-gt;RGB ? This Zen style of learning is turning out to be quite interesting...It is easy to be misled by Zen stories and koans in which practitioners attain enlightenment after a single word or deed, and don't realize that the practitioner involved usually meditated and studied for many years. Such uninformed people think they can become enlightened by reading a book or two.
I don't know the rationale behind the Cedocida option either.  As far as I know, if it is interlaced DV, set in Cedocida as MPEG2 interlaced YV12;  if you are lucky to able to capture in progressive DV mode, set it as MPEG2 progressive YV12.  Actually, I am wondering if those static/motion arguments apply in this case.  I wish I would have the mathematical mind to sort it out.

As for the conversion, YV12-gt;YUY2 itself is not a trivial task (search for the AutoYUY2() filter).  Also, the usage of RGB is rather limited nowadays.  As such, I think a two-step conversion is much acceptable for YV12-gt;RGB.

You are right. I guess the Cedocida options should have been labelled
Interlaced 4:2:0  instead of DV
Progressive instead of MPEG non interlaced
Interlaced 4:1:1 instead of MPEG interlaced
That's what it looks like, see showthread.php?t=103698

(I)
When encoding to DV and input is YV12 you have to tell the encoder which type of YV12 input you are feeding the encoder:
1.) quot;DVquot;, that is the luma and chroma samples are taken 1:1 for DCT-type compression as specified in the standard. If the source has sample positions which are not compliant to the DV standard you will get wrong results.
2.) quot;MPEG 2 non interlacedquot;, you are feeding in YV12 which is used in the MPEG 2 standard for non interlaced material. In order to get correct DV-compressed-video the position of the chroma samples are internally shifted/interpolated.
3.) quot;MPEG 2 interlacedquot;, same as 2.) but for interlaced MPEG 2 material
4.) When feeding the encoder with YUY2 or RGB material there is no uncertainty about the sample positions of luma/chroma, that is the quot;YV12 chroma samplingquot;-options are irrelevant.

(II)
When decoding from DV and output is YV12 you have to tell the encoder which type of YV12 output you want to get out of the decoder:
1.), 2.) and 3.) same as above but now specifies the output material.
4.) When decoding to YUY2 or RGB there is no uncertainty about the sample positions of luma/chroma, that is the quot;YV12 chroma samplingquot;-options are irrelevant.IMHO YV12 does only mean (in the broader sense), that there are 4 parts of luma and 2 parts of chroma samples for a 4-pixel-block, each 8bit per sample, and arranged in a planar way in memory. The position of the samples differs for the various video formats.
That is, if you deal with YV12, you have to tell what material you have (to feed the encoder) or you want to get (from the decoder).
DV compressed video does not distinguish between interlaced or progessive. DV-input and DV-output allways is considered as fields. It only has a mechanism to efficiently compress video which is progressive, i.e. if both fields are from the same time instance.

Regards, Andreas

Thanks for clearing it up once and for all !

I took the liberty of adding Andreas's explanation to the Readme.txt included in my hosted build of the codec. I also added a link in my main page for Hosted items.

(II)
When decoding from DV and output is YV12 you have to tell the encoder which type of YV12 output you want to get out of the decoder:
1.), 2.) and 3.) same as above but now specifies the output material.
4.) When decoding to YUY2 or RGB there is no uncertainty about the sample positions of luma/chroma, that is the quot;YV12 chroma samplingquot;-options are irrelevant.

Ok, now i'm completely confused.

Why is it that in (4) the chroma positions are not relevant? It seems to me you should know how to apply the weighting during upsampling. To apply the correct weighting you should know how the YV12 clip is sampled, thus you should know whether you are dealing with case 1, 2 or 3. Please clarify

edit: Ah, ok i got it now. quot;In order to get correct DV-compressed-video the position of the chroma samples are internally shifted/interpolated.quot; So the YV12-input is resampled for the cases 2 and 3. I didn't know that, and thought that the YV12 would be left in tact.

Originally Posted by A. DittrichDV-input and DV-output allways is considered as fields. It only has a mechanism to efficiently compress video which is progressive, i.e. if both fields are from the same time instance.

Does it refer to field based or frame based IDCT?

DV compressed video does not distinguish between interlaced or progessive. DV-input and DV-output allways is considered as fields. It only has a mechanism to efficiently compress video which is progressive, i.e. if both fields are from the same time instance.

I have to correct myself.
Probably you know this all, but because often I read something about progressive- / interlaced-DV and how to deal with this material, I think there is a little bit confusion.

Unlike MPEG-2 which has several modes for interlaced and progressive video, different DCT-types for fields, frames,  interlaced frames and different color sampling positions, for DV the following applies (to the best of my knowledge):

* DV-Video compresses a complete Frame (720x576 PAL, 720x480 NTSC)
color, aspect ratio etc. is based on analog video signal, digitized according to ITU-R REC.BT.601
* there is a flag in the header indicating that the encoded video is supposed to be interlaced or progressive, and a flag specifying the field order (tff/bff), but
* there is no special interlaced or progessive mode as in MPEG-2. The position of the color samples are allways the same and the macroblock and block areas are defined on the full frame. The only way to improve compression for interlaced or progressive material is to apply either the quot;normalquot; DCT or the 2-4-8-DCT (AFAIK only used in DV-compression) on the blocks (8x8 samples of one component). Every single block has a flag indicating the DCT type. So, even if the source material is progressive, for some blocks, compression could be better when choosing the 2-4-8-DCT and for interlaced vice versa.

To answer your question, Does it refer to field based or frame based IDCT?

In DV, we don't have a field based DCT/IDCT except this special 2-4-8-DCT which can be individually used for each block. All Macroblocks and Blocks are defined on the full frame.

@WilbertWhy is it that in (4) the chroma positions are not relevant? It seems to me you should know how to apply the weighting during upsampling. To apply the correct weighting you should know how the YV12 clip is sampled, thus you should know whether you are dealing with case 1, 2 or 3. Please clarify
I allways assume, that the compressed DV material, which maybe was created by Cedocida or some other codec or camera, is compliant to the DV standard. So there is no big uncertainty how to correctly upsample it to YUY2 or RGB.

@neuron2
Your welcome to add my little explanations to the Readme. Thx again for sharing the files.

Originally Posted by A. Dittrich* there is no special interlaced or progessive mode as in MPEG-2. The position of the color samples are allways the same ....

I don't understand........  if the color sample positions are always the same, what is the purpose of FixBrokenChromaUpsampling()?

For DV compressed video, the color sample positions are allways the same. But it is different to that of MPEG2-progressive and that of MPEG2-interlaced. If you decompress DV directly to YV12 (the option DV of Cedocida) without taking into account the color sample positions, you should fix it when further compressing to e.g. MPEG2.

@henryho_hk,

I think your question should be 'why does the free Canopus DV Codec v1.00 upsamples the chroma channels incorrectly'? People make mistakes

Just one correction to what A. Dittrich wrote - AFAIK there is no flag in DV stream specifying TFF/BFF. DV is assumed to be BFF always. Please correct me, if I'm wrong.