Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
3rd December 2005, 12:07 | #1 | Link |
Learning...
Join Date: Nov 2005
Location: 12.97°N, 77.56°E
Posts: 135
|
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 "copy" 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 & 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 ! Last edited by ariga; 3rd December 2005 at 12:55. |
3rd December 2005, 18:12 | #2 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
And you need to take into account "interlacing" as well. This page has excellent illustrations: http://www.mir.com/DMG/chroma.html
DV Codecs handle all these calculations, in their specific ways. We have the "DV decoder difference" and "DV decoder difference - update" threads here. |
5th December 2005, 11:19 | #3 | Link | |
Learning...
Join Date: Nov 2005
Location: 12.97°N, 77.56°E
Posts: 135
|
Towards enlightenment...
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->RGB. Is it always YV12->YUY2->RGB ? This Zen style of learning is turning out to be quite interesting...
Quote:
|
|
9th December 2005, 04:47 | #4 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
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->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->RGB. |
9th December 2005, 11:15 | #5 | Link |
Learning...
Join Date: Nov 2005
Location: 12.97°N, 77.56°E
Posts: 135
|
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 http://forum.doom9.org/showthread.php?t=103698 |
9th December 2005, 14:34 | #6 | Link |
Registered User
Join Date: Mar 2002
Posts: 38
|
(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.) "DV", 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.) "MPEG 2 non interlaced", 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.) "MPEG 2 interlaced", 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 "YV12 chroma sampling"-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 "YV12 chroma sampling"-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 |
9th December 2005, 17:51 | #9 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
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. "In order to get correct DV-compressed-video the position of the chroma samples are internally shifted/interpolated." 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. Last edited by Wilbert; 9th December 2005 at 17:56. |
|
10th December 2005, 13:30 | #10 | Link | |
Registered User
Join Date: Mar 2004
Posts: 889
|
Quote:
|
|
12th December 2005, 20:07 | #11 | Link | |||
Registered User
Join Date: Mar 2002
Posts: 38
|
Quote:
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 "normal" 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, Quote:
@Wilbert Quote:
@neuron2 Your welcome to add my little explanations to the Readme. Thx again for sharing the files. |
|||
15th December 2005, 15:23 | #12 | Link | |
Registered User
Join Date: Mar 2004
Posts: 889
|
Quote:
|
|
23rd December 2005, 23:53 | #13 | Link |
Registered User
Join Date: Mar 2002
Posts: 38
|
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.
|
13th July 2017, 21:32 | #16 | Link |
Registered User
Join Date: Jun 2006
Posts: 397
|
So according to that, what should be used when decoding PAL DV before encoding to h264?
Can anyone suggest DV test samples to clearly show the effect of wrong decode settings? BTW: The threads henryho_hk mentioned are these: https://forum.doom9.org/showthread.php?t=33526 https://forum.doom9.org/showthread.php?t=98847 Last edited by shae; 13th July 2017 at 21:39. |
|
|