DV decoder differences - update

[Wilbert]

I started with a new comparison. I'm looking at the following DV codecs:

1) Cedocida 0.1.6
2) Canopus 1.00.001 (does anyone have a newer version?)
3) MainConcept 2.4.16
4) DV codec in ff_vfw.dll
5) MS DV codec (directshow codec) for W2K
6) Panasonic (version unknown)
7) VDub v1.6.10's internal DV decoder

The following stuff is under investigation:

* lumarange behaviour [the conclusions in the sticky still apply; rest not done yet]
* encoder differences [not started yet]
* decoder differences [i'm looking only at PAL]

Before looking at the decoder differences, i will post what i think is the correct way of subsampling (YUY2 -> DV-YV12 interlaced conversion) and subsampling (DV-YV12 interlaced conversion -> YUY2). Please, let me know if you think the sampling is wrong. This will enable us to compare the theoretic results with the different sampling results of the DV codecs.

Theory: subsampling

YUY2 -> DV-YV12 interlaced conversion:

The layout of the *frame* is as follows

YUV1 ...
YUV2 ...
YUV3 ...
YUV4 ...
YUV5 ...
YUV6 ...
YUV7 ...
YUV8 ...

The new chroma samples are interpolated as follows:

YV1 ... V1 = ( 2*V1 + V3 )/3
YV2 ... V2 = ( 2*V2 + V4 )/3
YU3 ... U3 = ( U1 + 2*U3 + U5 )/4
YU4 ... U4 = ( U2 + 2*U4 + U6 )/4
YV5 ... V5 = ( V3 + 2*V5 + V7 )/4
YV6 ... V6 = ( V4 + 2*V6 + V8 )/4
YU7 ...
YU8 ...


Theory: upsampling

DV-YV12 interlaced conversion -> YUY2:

The layout of the *frame* is as follows

YV1 ...
YV2 ...
YU3 ...
YU4 ...
YV5 ...
YV6 ...
YU7 ...
YU8 ...

The missing chroma samples are interpolated as follows (note that the samples are taken from the same field, and the existing chroma is left untouched):

YV1 ... U1 = U3
YV2 ... U2 = U3
YU3 ... V3 = 0.5*( V1 + V5 )
YU4 ... V4 = 0.5*( V2 + V6 )
YV5 ... U5 = 0.5*( U3 + U7 )
YV6 ... U6 = 0.5*( U4 + U8 )
YU7 ...
YU8 ...


Decoder differences

To my surprise, if the sampling above is correct, all DV decoder produce incorrect output (ok, i didn't test all six of them yet). The sampling of the OS codec Cedocida 0.1.6 is the most accurate, but it is also incorrect.

I made a test clip with Cedocida 0.1.6 (selected YV12 - DV sampling). The resulting U values of each line are the following:

U3 = 16
U4 = 16
U7 = 16
U8 = 16
U11 = 16
U12 = 16
U15 = 16
U16 = 16
U19 = 16
U20 = 16
U23 = 16
U24 = 16
U27 = 16
U28 = 16
U31 = 30
U32 = 30
U35 = 34
U36 = 35
U39 = 38
U40 = 39


If the sampling (DV-YV12 interlaced conversion -> YUY2) above is correct, the decoders should produce the following output:

U1 = 16
U2 = 16
...
U27 = 16
U28 = 16
U29 = 23
U30 = 23
U31 = 30
U32 = 30
U33 = 32
U34 = 32.5 = 33
U35 = 34
U36 = 35
U37 = 36
U38 = 37
U39 = 38
U40 = 39


results for Cedocida:


U1 = 16
U2 = 16
...
U27 = 16
U28 = 16
U29 = 23
U30 = 23
U31 = 30
U32 = 30
U33 = 32
U34 = 33
U35 = 34
U36 = 35
U37 = 36
U38 = 37
U39 = 38
U40 = 39


results for Canopus:


U1 = 16
U2 = 16
...
U27 = 16
U28 = 16
U29 = 30
U30 = 30
U31 = 30
U32 = 30
U33 = 34
U34 = 34
U35 = 35
U36 = 35
U37 = 38
U38 = 38
U39 = 39
U40 = 39

It looks like the chroma is being duplicated instead of interpolated. The bad thing is that it is duplicated from the other field. This can be "corrected" by using FixBrokenChromaUpsampling. I will post screenshots which will prove this. Note that ScrollLock is correct in the other sticky.

results for MainConcept:


U1 = 16
U2 = 16
...
U23 = 16
U24 = 16
U25 = 15
U26 = 15
U27 = 15
U28 = 15
U29 = 31
U30 = 31
U31 = 31
U32 = 31
U33 = 33
U34 = 34
U35 = 33
U36 = 34
U37 = 39
U38 = 39
U39 = 39
U40 = 39

Uhm, what should i comment on this. This doesn't make any sense at all.

results for DV codec in ff_vfw.dll:

This codec outputs YV12.

results for MS DV codec:


U1 = 16
U2 = 16
...
U16 = 16
U17 = 15
U18 = 16
U19 = 15
U20 = 16
U21 = 15
U22 = 16
U23 = 15
U24 = 16
U25 = 15
U26 = 16
U27 = 15
U28 = 16
U29 = 30
U30 = 30
U31 = 30
U32 = 30
U33 = 33
U34 = 34
U35 = 33
U36 = 34
U37 = 38
U38 = 39
U39 = 38
U40 = 39

Uhm, what should i comment on this. This doesn't make any sense at all.

results for Panasonic codec:

Since Panasonic outputs RGB [0,255] I converted it back to YUY2:

U1 = 49
U2 = 49
...
U27 = 49
U28 = 49
U29 = 56
U30 = 56
U31 = 56
U32 = 56
U33 = 55
U34 = 56
U35 = 55
U36 = 56
U37 = 59
U38 = 58
U39 = 59
U40 = 58

This doesn't make any sense. More research is needed to find out what happens here.

results for VirtualDub v1.6.10 (internal dv decoder):

Exactly the same as for Cedocida.


edit: corrected U values of source.

To be continued ...

[Video Dude]

2) Canopus 1.00.001 (does anyone have a newer version?)


VideoHelp has the free version 1.02
http://www.videohelp.com/tools?tool=Canopus_DV_Codec

There are Canopus 2.x versions, but I believe they are only distributed with Canopus hardware products.

[Wilbert]

@Video Dude,

If i install that version and look at the properties in VDub, it still says 1.00.001?

[Video Dude]

It must be a mistake on the VideoHelp page. I guess 1.00.001 is the most up to date free version.

[madman_xxx]

BTW: Will VirtualDub's DV codec under testing too?

[bb]

BTW: Will VirtualDub's DV codec under testing too?
VirtualDub contains a DV decoder only, not a full codec.

bb

[henryho_hk]

I move the following from the "Reinterpolate420" thread because it seems a bit off-topic there.

To compare the PAL-DV decoding of some common DV codecs, I have made some image output thru' AVISynth's ImageWriter. The config is as follows:


Interlaced PAL DV clip created by a Sony DSR-PD150P
AviSynth 2.5.5
System YUY2 Codec = Huffyuv 2.1.1.1 w/ CE Patch
System YV12 codec = Helix YV12 1.2


The codecs tried are:

Canopus Playback-only 1.1.0.0
Cedocida 0.1.6 (hex-edited to use the FourCC "CDVE")
FFDShow 20050822
Panasonic 2.64.1119.1600 (hex-edited to use FourCC CDVP)
Sony 2.23 (hex-edited to use FourCC CDVS)


Observations:

Canopus seems to suffer from the chroma upsampling error (motion scene) but FixBrokenChromaUpsampling() introduces another chroma problem (static scene).
Cedocida YUY2 has no observable flaws; however, its YV12 output has the chroma heavily blurred (motion scene).
FFDShow's YUY2 and YV12 are both okay to me although YUY2 seems softer than others.
Panasonic's chroma does not look right (static scene)....
Sony's chroma does not look right either, though not as bad (static scene)....


I think FFDShow 20050822 is the YV12 winner for this PAL-DV clip. For YUY2, I vote for Cedocida.

The image files are available for reference:

<<deleted... refer to latter post>>

--------------------------------------------------------------
Cedocida's blurry YV12 is due to my wrong settings in the codec output.
Please refer to the following posts.
--------------------------------------------------------------


I have revised my previous codes. Any comment is welcomed:


t="motion"
#t="static"

sx = ( t == "motion" ) ? 240 : 560
sy = ( t == "motion" ) ? 360 : 410
lx = ( t == "motion" ) ? 160 : 160
ly = lx
dx = lx*3
dy = ly*3
cw = 720
ch = 576

# canopus
m_cdvc_yuy2=avisource("p3.avi",pixel_type="YUY2",fourcc="cdvc")
m_cdvc_yuyf=m_cdvc_yuy2.FixBrokenChromaUpsampling()

# cedocida
m_cdve_yuy2=avisource("p3.avi",pixel_type="YUY2",fourcc="cdve")
m_cdve_yv12=avisource("p3.avi",pixel_type="YV12",fourcc="cdve")

# ffdshow
m_dvsd_yuy2=avisource("p3.avi",pixel_type="YUY2",fourcc="dvsd")
m_dvsd_yv12=avisource("p3.avi",pixel_type="YV12",fourcc="dvsd")

# Panasonic
m_cdvp_rgb4=avisource("p3.avi",pixel_type="RGB24",fourcc="cdvp").ConvertTORGB32()

# Sony
m_cdvs_rgb4=avisource("p3.avi",pixel_type="RGB24",fourcc="cdvs").ConvertTORGB32()

#####################################################################
# Uncomment one by one for writing images... Are there better ways?
#####################################################################

#m_cdvs_rgb4.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_sony_rgb_",start=1,end=1,type="ebmp")
#m_cdvs_rgb4.crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_sony_rgb_f_a_",start=1,end=1,type="png")
#m_cdvs_rgb4.ConvertBackToYUY2().tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_sony_rgb_f_y_",start=1,end=1,type="png")
#m_cdvs_rgb4.ConvertBackToYUY2().utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_sony_rgb_f_u_",start=1,end=1,type="png")
#m_cdvs_rgb4.ConvertBackToYUY2().vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_sony_rgb_f_v_",start=1,end=1,type="png")

#m_cdvp_rgb4.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_panasonic_rgb_",start=1,end=1,type="ebmp")
#m_cdvp_rgb4.crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_panasonic_rgb_f_a_",start=1,end=1,type="png")
#m_cdvp_rgb4.ConvertBackToYUY2().tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_panasonic_rgb_f_y_",start=1,end=1,type="png")
#m_cdvp_rgb4.ConvertBackToYUY2().utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_panasonic_rgb_f_u_",start=1,end=1,type="png")
#m_cdvp_rgb4.ConvertBackToYUY2().vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_panasonic_rgb_f_v_",start=1,end=1,type="png")

#m_cdvc_yuy2.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_canopus_yuy2_",start=1,end=1,type="ebmp")
#m_cdvc_yuy2.crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopus_yuy2_f_a_",start=1,end=1,type="png")
#m_cdvc_yuy2.tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopus_yuy2_f_y_",start=1,end=1,type="png")
#m_cdvc_yuy2.utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopus_yuy2_f_u_",start=1,end=1,type="png")
#m_cdvc_yuy2.vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopus_yuy2_f_v_",start=1,end=1,type="png")

#m_cdvc_yuyf.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_canopusf_yuy2_",start=1,end=1,type="ebmp")
#m_cdvc_yuyf.crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopusf_yuy2_f_a_",start=1,end=1,type="png")
#m_cdvc_yuyf.tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopusf_yuy2_f_y_",start=1,end=1,type="png")
#m_cdvc_yuyf.utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopusf_yuy2_f_u_",start=1,end=1,type="png")
#m_cdvc_yuyf.vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_canopusf_yuy2_f_v_",start=1,end=1,type="png")

#m_cdve_yuy2.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_cedocida_yuy2_",start=1,end=1,type="ebmp")
#m_cdve_yuy2.crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_cedocida_yuy2_f_a_",start=1,end=1,type="png")
#m_cdve_yuy2.tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_cedocida_yuy2_f_y_",start=1,end=1,type="png")
#m_cdve_yuy2.utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_cedocida_yuy2_f_u_",start=1,end=1,type="png")
#m_cdve_yuy2.vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_cedocida_yuy2_f_v_",start=1,end=1,type="png")

#m_cdve_yv12.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_cedocida_yv12_",start=1,end=1,type="ebmp")
#m_cdve_yv12.ConvertToRGB24(interlaced=true).crop(sx,sy,lx,ly).PointResize(dx,dy).imagewriter(file="pal_"+t+"_cedocida_yv12_i_a_",start=1,end=1,type="png")
#m_cdve_yv12.ConvertToRGB24(interlaced=false).crop(sx,sy,lx,ly).PointResize(dx,dy).imagewriter(file="pal_"+t+"_cedocida_yv12_f_a_",start=1,end=1,type="png")
#m_cdve_yv12.tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_cedocida_yv12_f_y_",start=1,end=1,type="png")
#m_cdve_yv12.utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_cedocida_yv12_f_u_",start=1,end=1,type="png")
#m_cdve_yv12.vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_cedocida_yv12_f_v_",start=1,end=1,type="png")

#m_dvsd_yuy2.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_ffdshow_yuy2_",start=1,end=1,type="ebmp")
#m_dvsd_yuy2.crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_ffdshow_yuy2_f_a_",start=1,end=1,type="png")
#m_dvsd_yuy2.tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_ffdshow_yuy2_f_y_",start=1,end=1,type="png")
#m_dvsd_yuy2.utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_ffdshow_yuy2_f_u_",start=1,end=1,type="png")
#m_dvsd_yuy2.vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_ffdshow_yuy2_f_v_",start=1,end=1,type="png")

#m_dvsd_yv12.crop(sx,sy,lx,ly).imagewriter(file="pal_"+t+"_ffdshow_yv12_",start=1,end=1,type="ebmp")
#m_dvsd_yv12.ConvertToRGB24(interlaced=true).crop(sx,sy,lx,ly).PointResize(dx,dy).imagewriter(file="pal_"+t+"_ffdshow_yv12_i_a_",start=1,end=1,type="png")
#m_dvsd_yv12.ConvertToRGB24(interlaced=false).crop(sx,sy,lx,ly).PointResize(dx,dy).imagewriter(file="pal_"+t+"_ffdshow_yv12_f_a_",start=1,end=1,type="png")
#m_dvsd_yv12.tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_ffdshow_yv12_f_y_",start=1,end=1,type="png")
#m_dvsd_yv12.utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_ffdshow_yv12_f_u_",start=1,end=1,type="png")
#m_dvsd_yv12.vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).ConvertToRGB24(interlaced=false).imagewriter(file="pal_"+t+"_ffdshow_yv12_f_v_",start=1,end=1,type="png")

[tulikanuj]

@henryho_hk,
a) what do you think about Arithyuv Codec? It's comparison to other codec will assist other to decide which one to get.
b) your video format was PAL. Will it be true for NTSC. Do you know if anyone has done such comparison for NSTC (or if you have plan to do one in NTSC format).

[henryho_hk]

@henryho_hk,
what do you think about Arithyuv Codec?


Actually, I don't know if Huffyuv is having any significance in my test as I perform all operation within AVISynth. I shall test Arithyuv if it matters.

[henryho_hk]

I test the codecs again with a NTSC clip, which was posted in the XVID forum some time ago (the clip is called dvsample.avi but I can't find the thread now).

The snapshots are as follow. Please note that the YV12 png outputs should not be compared directly with the PAL files because i have added "ConvertToYUY2(interlaced=true)" this time. Don't worry, the ebmp files are intact.

<<deleted... refer to latter post>>

Observations:


Canopus does not have the chroma upsampling problem as in PAL.
Cedocida's YV12 is again blurry, and its YUY2 has strange horizontal lines in the very right side of its chroma output.
FFDShow's YV12 has a serious chroma shift of over 8 pixels horizontally (look at the blue object at the lower left).
Panasonic's chroma output is simply different from others.....
I find it very interesting to discover that their chroma output forms 2 groups concerning horizontal placement, Canopus and FFDShow's YUY2 as one, Sony, Panasonic & Cedocida as another.


This time, I don't know who's right and who's wrong.

----------------------------------------------------------

update - i have forgotten to set the proper cedocida yv12 output mode, causing the blurry chroma. the snaphots have been corrected now.

[KR]

Hi all,

I've experienced the following problem for about 3~4 months: I would capture the video from my DV camcorder and use VDub filter "Deinterlace - smooth" to make the video slow motion. During high-motion scenes in the video, some blocks in ex: frame t seemed to belong to frame t+1, and the same groups of pixels in frame t+1 seemed to come from frame t. As if parts of two frames (meaning two fields in the original video) were interchanged. This appeared only on the edges, during high-motion.

I first tough it was because of the filter, so I used other filters and the problem was still there. The problem was not Vdub(Mod) either. I even reformated and reinstalled Windows. I worried that it could be the camcorder, etc.

It turned out that the problem was Sony DV Codec. The problem shows up whenever it has to decode really high-motion video (ex: martial arts movements, or quick panning). If I remember correctly, VirtualDub1.6.10's internal decoder has the same problem, but Sony Dv Codec is worse. I now use MainConcept Codec.

[henryho_hk]

I added Adaptec and Mainconcept to my codec comparsion. Also, I generated all the output files again using stackvertical and horizontal for better comparsions.

Note: I have uploaded the images to imageshack. See posts below.

http://www.geocities.com/henryho_hk/ntsc_motion_1.zip
http://www.geocities.com/henryho_hk/ntsc_motion_2.zip
http://www.geocities.com/henryho_hk/ntsc_motion_3.zip
http://www.geocities.com/henryho_hk/pal_motion.zip
http://www.geocities.com/henryho_hk/pal_static.zip

Code:

function makeRow(clip c, string cc4, string csp, int cw, int ch, int sx, int sy, int lx, int ly, int dx, int dy)
{
c_f=c.PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).Subtitle(csp+"/f").ConvertToRGB24(interlaced=true)
c_y=c.tweak(sat=0).PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).Subtitle(csp+"/y").ConvertToRGB24(interlaced=false)
c_u=c.utoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).Subtitle(csp+"/u").ConvertToRGB24(interlaced=false)
c_v=c.vtoy().PointResize(cw,ch).crop(sx,sy,lx,ly).PointResize(dx,dy).Subtitle(csp+"/v").ConvertToRGB24(interlaced=false)

stackhorizontal(c_f,c_y,c_u,c_v)
}

function makeFrame(string clipname, string cc4, string codecname, int framenum)
{
m=directshowsource(clipname,audio=false)
cw=width(m)
ch=height(m)

# PAL Motion
#sx = 240
#sy = 360

# PAL Static
#sx = 560
#sy = 410

# NTSC Motion 1
#sx = 96
#sy = 108

# NTSC Motion 2
#sx = 316
#sy = 104

# NTSC Motion 3
sx = 540
sy = 272

lx = 160
ly = 160
dx = lx*1
dy = ly*1

Try {
m_rgb4=avisource(clipname,pixel_type="RGB24",fourcc=cc4,audio=false).ConvertBackToYUY2()
} Catch(err_msg_1) {
m_rgb4=BlankClip(m,pixel_type="yuy2")
}
m_rgb4=m_rgb4.trim(framenum,-1)

Try {
m_yuy2=avisource(clipname,pixel_type="YUY2",fourcc=cc4,audio=false)
} Catch(err_msg_2) {
m_yuy2=BlankClip(m,pixel_type="yuy2")
}
m_yuy2=m_yuy2.trim(framenum,-1)

Try {
m_yv12=avisource(clipname,pixel_type="YV12",fourcc=cc4,audio=false).ConvertToYUY2(Interlaced=true)
} Catch(err_msg_3) {
m_yv12=BlankClip(m,pixel_type="yuy2")
}
m_yv12=m_yv12.trim(framenum,-1)


r1=makeRow(m_yv12, cc4, "yv12", cw, ch, sx, sy, lx, ly, dx, dy)
r2=makeRow(m_yuy2, cc4, "yuy2", cw, ch, sx, sy, lx, ly, dx, dy)
r3=makeRow(m_rgb4, cc4, "rgb", cw, ch, sx, sy, lx, ly, dx, dy)

stackvertical(r1, r2, r3).subtitle(codecname,align=5,x=-1,y=-1)
}


f="dvsample.avi"
framenum=249

#f="p3.avi"
#framenum=2

cc4="cdvc"

p0=makeFrame(f, "cdva", "Adaptec 1.11", framenum)
p1=makeFrame(f, "cdvc", "Canopus (Playback) 1.1.0.0", framenum)
p2=makeFrame(f, "cdve", "Cedocida 0.1.6", framenum)
p3=makeFrame(f, "cdvm", "Mainconcept 2.4.16.0", framenum)
p4=makeFrame(f, "cdvp", "Panasonic 2.64.1119.1600", framenum)
p5=makeFrame(f, "cdvs", "Sony 2.23.0.0", framenum)
p6=makeFrame(f, "dvsd", "FFDShow 2005/08/22", framenum)

interleave(p0,p1,p2,p3,p4,p5,p6)
converttorgb24().imagewriter(type="png")

[henryho_hk]

Sorry to all.... I fail to set the "YV12" output setting of Cedocida properly as "YV12 MPEG2 Interlaced" when generating the snapshots. It may explain for "blurry" chroma observed in the previous Cedocida YV12 shapshots. I will update the snapshot files as soon as possible.

------------------------------------------------------

To all developers of Cedocida, please accept my apology. The blurried chroma of Cedocida in YV12 is simply due to my failure to select the correct YV12 output mode. I have updated all the snapshot zip files already. I have included the MS DV decoder output as well. Please enjoy.

[henryho_hk]

Disclaimer: (1) These are my own impression only. ^_^
(2) These tables do not take into other quality factors like color, tone, details, contrast, etc.

Note: I have removed the confusing YV12 rows as advised by Wilbert.

====================================================================================================
YUY2 | FixBrokenChromaUpsampling() | Reinterpolate411() | Reinterpolate420()
Functions +-----------------------------+--------------------+--------------------
Needed ? | NTSC | PAL | NTSC | PAL
----------------------------+--------------+--------------+--------------------+--------------------
Canopus 1.1.0.0 Free | N | Y | Y | Y
Cedocida 0.1.6 | N | N | N | N
FFDShow 2005/10/13 | N | N | Y | N
Mainconcept 2.4.16.0 Demo | N | N | Y | Y
MS DV Show DX 9.0c | N | N | N | Y
====================================================================================================


====================================================================================================
RGB | FixBrokenChromaUpsampling() | Reinterpolate411() | Reinterpolate420()
Functions +-----------------------------+--------------------+--------------------
Needed ? | NTSC | PAL | NTSC | PAL
----------------------------+--------------+--------------+--------------------+--------------------
Adaptec 1.11 | N | N | Y | Y
Canopus 1.1.0.0 Free | N | Y & strange | Y | Y
Cedocida 0.1.6 | N | N | N | N
FFDShow 2005/10/13 | N | Y & strange | Y | N
Mainconcept 2.4.16.0 Demo | N | N | Y | Y
MS DV Show DX 9.0c | N | N | N | Y
Panasonic 2.64.1119.1600 | N | N | N | Y
Sony 2.23.0.0 | N | N | N | N
====================================================================================================


====================================================================================================
YV12 | FixBrokenChromaUpsampling() | Reinterpolate411() | Reinterpolate420()
Functions +-----------------------------+--------------------+--------------------
Needed ? | NTSC | PAL | NTSC | PAL
----------------------------+--------------+--------------+--------------------+--------------------
Cedocida 0.1.6 | N | N | N | N
FFDShow 2005/10/13 | N | N | Y & Incorrect | N
====================================================================================================

[Wilbert]

I don't get your YV12 column. Most of the DV decoders don't output YV12 (except cedocida and ffdshow).

[henryho_hk]

I forgot to mention that the MS DV decodes the NTSC DV video at exactly one frame ahead of others but there is no such problem for PAL DV. I am sorry that I dun have the golden ear to verify if it applies to the audio too.

[henryho_hk]

NTSC Motion 1

http://img394.imageshack.us/img394/6350/adaptec8rp.png
http://img394.imageshack.us/img394/8238/canopus7mw.png
http://img394.imageshack.us/img394/8413/cedocida6ez.png
http://img138.imageshack.us/img138/6922/ffdshow1ph.png
http://img55.imageshack.us/img55/1817/mainconcept4ko.png
http://img495.imageshack.us/img495/2682/msdv3yr.png
http://img495.imageshack.us/img495/9666/panasonic1sl.png
http://img495.imageshack.us/img495/1443/sony5dl.png

========================================================

NTSC Motion 2

http://img69.imageshack.us/img69/1182/adaptec5yv.png
http://img488.imageshack.us/img488/5819/canopus9ts.png
http://img488.imageshack.us/img488/669/cedocida8or.png
http://img488.imageshack.us/img488/5600/ffdshow7wt.png
http://img488.imageshack.us/img488/737/mainconcept4kp.png
http://img488.imageshack.us/img488/4422/msdv7km.png
http://img488.imageshack.us/img488/351/panasonic3ha.png
http://img488.imageshack.us/img488/3623/sony4hv.png

========================================================

PAL Motion

http://img142.imageshack.us/img142/7687/adaptec0dl.png
http://img142.imageshack.us/img142/8742/canopus5gz.png
http://img142.imageshack.us/img142/1906/cedocida5yy.png
http://img142.imageshack.us/img142/76/ffdshow6rp.png
http://img142.imageshack.us/img142/766/mainconcept6tw.png
http://img147.imageshack.us/img147/8118/msdv7uk.png
http://img147.imageshack.us/img147/6808/panasonic1lr.png
http://img147.imageshack.us/img147/5872/sony5pv.png

========================================================

PAL Static

http://img147.imageshack.us/img147/5219/adaptec2zv.png
http://img147.imageshack.us/img147/551/canopus6pk.png
http://img147.imageshack.us/img147/3006/cedocida8gq.png
http://img147.imageshack.us/img147/1025/ffdshow5la.png
http://img147.imageshack.us/img147/3957/mainconcept1ij.png
http://img147.imageshack.us/img147/7184/msdv6hl.png
http://img147.imageshack.us/img147/7433/panasonic8ul.png
http://img147.imageshack.us/img147/777/sony6rv.png

[WorBry]

On previously testing the Canopus DV codec v1.02 with my Pal DV sources, I encountered the famed ‘broken chroma upsampling’ effect, at least on my desktop PC (AMD 2800 XP processor, XP Pro/ SP2). ‘Fixbrokenchromaupsampling’ fixed it, but at the expense of a significant drop in quality as judged by some quality metric measures (PSNR etc).

Intrigued by reports that more recent versions do not exhibit the ‘bug’, I installed the demo version of Procoder 2, this time on my laptop (IBM ThinkPad R50e, Pentium Centrino M 1.60 GHz, XPPro/SP2). First off, I was surprised to find that the demo (from the Canopus website) is actually v 1.25.15.0. On checking the installed DV codec with VCSwap, I was also surprised to find that it (cdvccodc.dll) was version 1.02. More surprising was that when I tested the codec for DV decompression in VirtualDub, this time there was no evidence of ‘broken chroma upsampling’. In fact, applying the AVS fix filter actually manifested the effect.

Out of interest, I uninstalled the Procoder demo and re-installed my old copy of v1.02, with the same result. Strange I thought. So I installed v1.02 again on my desktop, and sure enough, there was the broken chroma bug again. I double checked that I was using the same versions of AVISynth (2.56) and VDubMod (1.5.10.2 Build 2452) on both PC’s, which I was.

Can anyone suggest why I would be seeing the bug on one PC but not the other? I’m wondering if maybe the Procoder installation left some ‘helper’ files on my laptop that ensure proper chroma upsampling. Of course this could be answered by installing the demo on my desk-top also, but I am reluctant to do so because I read somewhere that Procoder and TMPGenc don’t like each other.

After this I also found a copy of Canopus DV codec v4.04. Thinking this to be a more recent version, I installed it, only to find that the cdvccodc.dll was v1.01.003, seemingly an older version. However, after removing this codec (with VCSwap) and re-installing 1.02 or the Procoder demo, VCSwap still shows the codec to be 1.01.003. Very strange ??

I am otherwise using the Cedocida DV codec as my working codec, but might consider changing to Canopus for YUY2 output because of the better compression I am seeing in comparative tests (on my laptop). If only I could achieve the same on my AMD.

[WorBry]

Well, if anybody is interested :( , I did the same on my desktop; installed and uninstalled the Procoder2 demo, noting not too delete the "these files are no longer needed ...etc" files when prompted in the deinstallation. Lo and behold, no chroma sampling error :) . I didnt note at the time what the residial dll's were but on running a registry check with RegCleaner, one appears to a remnant of the DV Booster Pack, in addition to the cdvccodc.dll decoder itself. This leaves me convinced that the so called "broken chroma upsampling bug" arises because the Canopus DV decoder was not intended to work in isolation from other files in the codec pack that assist in correct chroma upsampling.

However, my above claim that "Canopus-decoded" DV is more compressible than Cedocida (YUY2) was a little premature :rolleyes: . On further testing with a variety of clips, they appear to be very much the same.

[henryho_hk]

You need to take a look at the registry to verify which DLL is picking up the vfw DV decoding job.

[Fizick]

It is interesting.
Try find and compare CSCCDVC.DLL version.
It is real Canopus codec DLL (not frontend).

[lilhobo]

will there be some sort of english summary of the codec....i cant decipher those figures lol :D

[Terka]

so which one do you suggest to use?

[lilhobo]

use www.youtube.com yahoo.videos or google videos to upload your samplaes ;)

[WorBry]

It is interesting.
Try find and compare CSCCDVC.DLL version.
It is real Canopus codec DLL (not frontend).

Hi Fizick,

I cant say I looked into this phenomenon any further as I've now settled on the Cedocida DV codec as my standard decoder, for several reasons:

a) Prefer to process in YV12 throughout i.e. no color space conversions at any point from decoding, through AVS processing (deinterlace, denoise) to final rendering, either as FFDShow-HuffYUV (YV12) archive or MPEG-4/AVC

b) With my DV sources at least, the Canopus DV codec (even in the absence of chroma upsampling error) tends to suffer from some chroma bleed. In my own comparative tests, the only three decoders that avoided this were:

Cedocida DV codec - provided 'forced' YV12 output is set to 'MPEG-2 interlaced' YV12 sampling.

Sony DV codec - outputs RGB only and requires finicky correction of luma shift after conversion to YUV

Matrox DV codec - outputs RGB only and appears also to suffer from some chroma upsampling error after conversion to YUV . Havent investigated this further.

c) Canopus output is a little too grainy for my personal preference.

All I can say about the 'fixed' upsampling phenomenon I described before is, in summary:

1. Canopus codec installed on its own (i.e. cdvccodc.dll. v1.02 or v1.01.003 contained in Canopus DV codec package v4.04) results in chroma upsampling error.

2. Installation of Procoder 2 demo (containing cdvccodc.dll. v1.02) - no chroma upsampling error.

3. If uninstall Procoder 2 demo and then install cdvccodc.dll v1.02 or Canopus DV codec package v4.04 - still no upsampling error. In the former case, VCSwap (with all other vfw DV codecs inactivated) and VirtualDub (File Info and Compression settings) confirms the codec to be cdvccodc.dll v1.02.000. In the second case, VCSwap shows the active codec to be v1.01.003 wheras VirtualDub lists it as 'Canopus DV codec for DV Booster Pack'. In either case the Canopus components still remaining in the registry on my PC (as revealed by RegistryCleaner) are:

cdvccodec
MVR Compatible
Soft Engine

I have no idea whether the last two are components of a front-end, back-end or whatever, but it is reasonable to conclude that they in some way interact with the native cdvccodec.dll to ensure correct upsampling.

Indeed, it would not make sense for a company to (continue to) incorporate a codec in its products that is inherently defective. Have Canopus themselves ever commented on this?

[henryho_hk]

Prefer to process in YV12 throughout i.e. no color space conversions at any point from decoding, through AVS processing (deinterlace, denoise) to final rendering, either as FFDShow-HuffYUV (YV12) archive or MPEG-4/AVC

You will always "suffer" from colorspace conversion because PAL DV YV12 and MPEG2/4 YV12, although both named "4:2:0", are substantially different. In MPEG2/4, the Cb and Cr samples cosite horizontally and, in PAL DV, the Cb and Cr samples are located on alternate lines. Hence, the DV codec needs to perform colorspace conversion to give MPEG2/4 YV12 output. Actually, I don't know any codec other than Cedocida and FFDShow having YV12 supports.

http://en.wikipedia.org/wiki/4:2:0
http://www.mir.com/DMG/chroma.html

[dosdan]

You will always "suffer" from colorspace conversion because PAL DV YV12 and MPEG2/4 YV12, although both named "4:2:0", are substantially different. In MPEG2/4, the Cb and Cr samples cosite horizontally and, in PAL DV, the Cb and Cr samples are located on alternate lines. Hence, the DV codec needs to perform colorspace conversion to give MPEG2/4 YV12 output. Actually, I don't know any codec other than Cedocida and FFDShow having YV12 supports.



Henry does this mean that, if the source is PAL-DV and the dest. is PAL-DVD (I), I should be using YV12 Mpeg-2 (I) as the decorder output format rather than YV12 DV?

[WorBry]

Henryho_hk,

Thanks for the enlightenment; I didnt realize that the subsampling was so different. Still, keeping in YV12 has some advantages for AVS processing speed (especially with MVBob) and final archive size i.e. FFDShow HuffYuv-YV12 gives substantially lower file sizes than YUY2 with native HuffYuv v2.1.1.

On that note, I'm now wondering if it is certain that FFDShow HuffYuv preserves the YV12 subsample format of the input source, which, in my current process flow, I assume would be 'MPEG-2 progressive' (after deinterlacing) ?

[henryho_hk]

f the source is PAL-DV and the dest. is PAL-DVD (I), I should be using YV12 Mpeg-2 (I) as the decorder output format rather than YV12 DV?

You should not select "YV12 DV" if you want to perform DVD encoding. As for RGB, YUY2 or YV12 (MPEG2-I), your Cedocida output option should match with your DVD encoding software (e.g., RGB for TMPGEnc). You can also try HC Encoder which is free and YV12 (MPEG2 I or P) native.

[henryho_hk]

WorBry, it all depends on your destination. If you want to make archive, I think you should keep the DV AVI dump files (aren't they smaller than Huffyuv?).

In addition, if you are encoding to DVD, I suggest you NOT to deinterlace your DV footage. Simply use the ReverseFieldDominance() filter to change it from BFF to TFF will do.

For FFDShow, since there is also a "DV" output option (2006/07/29 version), I think its YV12 refers to the MPEG2 one (though I am not sure how it differentiates between interlaced or progressive DV inputs).

[WorBry]

henryho_hk

Yes, I do keep the original DV footage, but given the time it takes to deinterlace (with MVBob) I also now archive my processed deinterlaced/denoised clips as 'lossless' masters for conversion to working formats including DivX, XviD (for 50fps renders) and more recently x264. The MSU lossless codec also works well with even more economy in file size, but playback is very slow. So for now, FFShow HuffYuv-YV12 best meets the need, as long as my dwindling memory (hard-drive that is :D) holds out.

For conversion to DVD I, as you advise, never deinterlace, only separate fields, mild-denoise and re-weave. I was merely referring to the fact that in the above 'interlaced to progressive archive' workflow the YV12 (MPEG2 interlaced) output from Cedocida surely changes to a YV12 (MPEG2 deinterlaced) subsample format, assuming I understand these terms correctly.

Thanks for your pointer on the FFDShow DV output function. I'll look into that, as it might come in useful for DV standards conversion, for which I currently use Scharfis_Brain's (mvbob package) functions, again via HuffYuv intermediates. In this case, the process does involve deinterlacing for frame rate conversion before reinterlacing. However, MugFunky's latest 'one step' process also looks promising.

I digress.

Edit: Do you have a link for that FFDShow build? Cant find it.

[henryho_hk]

WorBry,

If your DV is interlaced, tell Cedocida to give you MPEG2 interlaced YV12. Otherwise, the chroma (color) information will be incorrect. Try looking at the comb area of a white object moving over a red background. If you ask Cedocida to give you MPEG2 non-interlaced YV12, you will find the white comb pattern appearing pink. Instead, it should stay in white (no color bleed), as when you tell Cedocida to give MPEG2 interlaced output.

BTW, "tdeint" is also an excellent deinterlacer.

Looking for FFDShow? Take a look at the room "New and alternative video codecs".

[WorBry]

If your DV is interlaced, tell Cedocida to give you MPEG2 interlaced YV12. Otherwise, the chroma (color) information will be incorrect. Try looking at the comb area of a white object moving over a red background. If you ask Cedocida to give you MPEG2 non-interlaced YV12, you will find the white comb pattern appearing pink. Instead, it should stay in white (no color bleed), as when you tell Cedocida to give MPEG2 interlaced output.

Yes, thats exactly what I observed and do - output MPEG2 interlaced YV12

[Terka]

as for as me - non expirenced user, what codec should i use and what command to recover its bug?

[henryho_hk]

as for as me - non expirenced user, what codec should i use and what command to recover its bug?

See if my previous post (http://forum.doom9.org/showthread.php?p=730233#post730233) helps.

Cedocida is a good choice. Just remember to set its output to "MPEG2 Interlaced YV12" if you have an interlaced DV camera and you want to try AVS scripts.

[Terka]

even if i want to encode to 50p Xvid?

[henryho_hk]

even if i want to encode to 50p Xvid?

I suppose that you are using some bob() filters to convert your 25i movie to 50p. Cedocida is able to deliver correct outputs for your bob() filter. BTW, XviD supports interlaced encoding too.

[Terka]

yes deinterlace smooth, thanks

[WorBry]

Terka,

I assume you are referring to the AVS import of Smooth Deinterlace, which accepts YV12. Otherwise, if you were using the original VDub filter, you would probably be best outputting RGB.

For 50fps deinterlacing, I prefer MVBob myself. As slow as it is, some things are worth waiting for. I see you initiated a thread on this subject over in

http://forum.doom9.org/showthread.php?p=855335#post855335

Looks like there's some good things brewing there, eh? Exciting stuff.

BTW - IMHO, AutoGK handles XviD 50fps encoding very nicely; hence one of the reasons why I render my deinterlaced/denoised DV sources as FFDShow-HuffYuv (YV12) 'masters', since (afaik)AutoGK doesnt accept AVS scripts. It's a bit of a pain waiting for the analysis to tell you that the source is progressive, which you already know, but the results are excellent. I'm now experimenting with MeGUI and x264.

BTW(2) - I wonder if anyone is inclined to compile a binary for the modified Cedocida codec with built in analyzer that was posted some time ago

http://forum.doom9.org/showthread.php?p=773799#post773799

I would if I could.

[WorBry]

You will always "suffer" from colorspace conversion because PAL DV YV12 and MPEG2/4 YV12, although both named "4:2:0", are substantially different. In MPEG2/4, the Cb and Cr samples cosite horizontally and, in PAL DV, the Cb and Cr samples are located on alternate lines. Hence, the DV codec needs to perform colorspace conversion to give MPEG2/4 YV12 output.

I see Fizick has looked at the Cedocida source code and concluded that the conversion from YV12 (DV) to YV12 (MPEG2) actually proceeds via a YUY2 intermediate, as also does conversion to RGB. Only YV12 (DV) output remains untouched.

http://forum.doom9.org/showthread.php?p=860905#post860905

So much for my naive notion of ''staying in YV12'' to avoid color space conversions :rolleyes:

[henryho_hk]

@WorBry, AviSynth does not know DV 4:2:0. It always takes it as MPEG2 4:2:0. Indeed, it does not know whether it is progressive or interlaced (which IMO is not equivalent to "field-based"). And I think AviSynth 2.56 will throw an error if you run ConvertToYV12(Interlaced=xxx) on an DV 4:2:0 source.

[scharfis_brain]

No it won't throw an error.
It simply doesn't know the difference between MPEG2 YV12 and DV YV12, because both are transferred to AVISynth using the YV12 FOURCC.

[WorBry]

And I think AviSynth 2.56 will throw an error if you run ConvertToYV12(Interlaced=xxx) on an DV 4:2:0 source.

Actually, no it doesnt - I've just double-checked.

Cedocida set to 'forced YV12 (DV sampling)' output with

avisource("C:\DV Type II.avi")
ConvertToYV12(interlaced=true)

opens just fine in VdubMod. File Info gives 'DivX 6.2.5 YV12 Decoder' as the (stream) decompressor.

Edit: Sorry Scharfis, you got there before me.

[henryho_hk]

Thanks for correcting me, scharfis_brain & WorBry.

[aabxx]

This thread is confusing.

So did anyone come to any conclusions about what to use and what not to use?

[swiego]

I'm wondering too.

I'm glad to have found this (I think), as I'd assumed that DV decoders wouldn't make a difference. Of course maybe that is the case after all... are the differences significant?

[henryho_hk]

See the screen caps here:
http://forum.doom9.org/showthread.php?p=733216#post733216

[aabxx]

After studying this thread cedocida seems to be the best option.

To swiego:
The differences are significant. At least to a fairly experienced video encoder. For the casual observer they are probably only minor and in fact the added sharpness of some decoders only makes the stuff look better to them :P Chroma bugs can be noticeable on some material while on other they can be difficult to observe [under normal playback that is].

[lilhobo]

Latest version:
0.1.7 (Nov 22, 2006)

Main tool site and mirror download site:
Main tool site - 150KB
Mirror download - 150KB

[swiego]

So, what decoder ships with Windows Vista? I installed Vista Ultimate and was able to play all my DV files out-of-the-box. I was wondering if this is one of the decoders described and tested in this thread, or something new. (I played the files with both windows home premium and windows ultimate.)

Just curious.