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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > DV

Reply
 
Thread Tools Search this Thread Display Modes
Old 3rd December 2005, 12:07   #1  |  Link
ariga
Learning...
 
ariga's Avatar
 
Join Date: Nov 2005
Location: 12.97N, 77.56E
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.
ariga is offline   Reply With Quote
Old 3rd December 2005, 18:12   #2  |  Link
henryho_hk
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.
henryho_hk is offline   Reply With Quote
Old 5th December 2005, 11:19   #3  |  Link
ariga
Learning...
 
ariga's Avatar
 
Join Date: Nov 2005
Location: 12.97N, 77.56E
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:
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.
ariga is offline   Reply With Quote
Old 9th December 2005, 04:47   #4  |  Link
henryho_hk
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.
henryho_hk is offline   Reply With Quote
Old 9th December 2005, 11:15   #5  |  Link
ariga
Learning...
 
ariga's Avatar
 
Join Date: Nov 2005
Location: 12.97N, 77.56E
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
ariga is offline   Reply With Quote
Old 9th December 2005, 14:34   #6  |  Link
cedocida
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
cedocida is offline   Reply With Quote
Old 9th December 2005, 15:08   #7  |  Link
ariga
Learning...
 
ariga's Avatar
 
Join Date: Nov 2005
Location: 12.97N, 77.56E
Posts: 135
Thanks for clearing it up once and for all !
ariga is offline   Reply With Quote
Old 9th December 2005, 16:01   #8  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,924
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.
Guest is offline   Reply With Quote
Old 9th December 2005, 17:51   #9  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,295
Quote:
(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.
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. "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.
Wilbert is offline   Reply With Quote
Old 10th December 2005, 13:30   #10  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Quote:
Originally Posted by A. Dittrich
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.
Does it refer to field based or frame based IDCT?
henryho_hk is offline   Reply With Quote
Old 12th December 2005, 20:07   #11  |  Link
cedocida
Registered User
 
Join Date: Mar 2002
Posts: 38
Quote:
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 "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:
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.

@Wilbert
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
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.
cedocida is offline   Reply With Quote
Old 15th December 2005, 15:23   #12  |  Link
henryho_hk
Registered User
 
Join Date: Mar 2004
Posts: 889
Quote:
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()?
henryho_hk is offline   Reply With Quote
Old 23rd December 2005, 23:53   #13  |  Link
cedocida
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.
cedocida is offline   Reply With Quote
Old 24th December 2005, 01:51   #14  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,295
@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
Wilbert is offline   Reply With Quote
Old 4th February 2006, 21:05   #15  |  Link
vlada
Registered User
 
Join Date: Apr 2003
Location: Czech Republic
Posts: 752
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.
vlada is offline   Reply With Quote
Old 13th July 2017, 21:32   #16  |  Link
shae
Registered User
 
Join Date: Jun 2006
Posts: 320
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.
shae is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.