DV decoder differences

[cweb]

Originally posted by Lycaon
That's because libavcodec is Converting the DV (YV12 4:1:1) into YV12 4:2:0. I wouldn't recommend you use libavcodec for DV material.

PAL DV is YV12 4:2:0 however, so in that case there would be no conversion, and libavcodec can be recommended for PAL DV at least.
libavcodec seems to give me good results for PAL DV, in fact.

Perhaps you can try the new open source DV decoder (mentioned in the sticky) once there is NTSC decoding available.

[Wilbert]

@bb,

Could you correct something in the first post of this thread.

Canopus DV Codec V1.00
(...) A big issue with this decoder is that it has a nasty "chroma upsampling bug". This bug exists for both YUV2 and RGB. Fortunately this bug can be fixed using AVISynth's function "FixBrokenChromaUpsampling".

FixBrokenChromaUpsampling doesn't fix this chroma problem. You should use Reinterpolate411 here, because it reinterpolates the duplicated chroma lines (duplicated by the codec in YV12->YUY2).

The FixBrokenChromaUpsampling filter fixes a chroma problem in the MS DV codec:

http://forum.doom9.org/showthread.ph...291#post693291
http://www.avisynth.org/FixBrokenChromaUpsampling

Btw, for clarity, both of these problems have nothing to do with the famous 'Chroma Upsamping Error'.

edit: sorry for posting nonsense.

1) This is indeed an example of the famous CUE. In the YV12->YUY2 conversion point sampling is done by copying chroma from the other field, which results in the CUE. This happens with the free Canopus decoder, and more recent (non-free) versions don't seem to have this problem.

2) This chroma problem in not present in the MS DV codec. At least for DirectX8/9, perhaps it is present in DirectX7, but i still need to check that.

[SimonSez07]

i understand the canopus dv codec has this "chroma upsampling bug" that causes it to duplicate chroma lines when rendering NTSC DV (4:1:1) to YUY2 colorspace (4:2:2). and this bug can supposedly be corected in avisynth by adding Reinterpolate411() after AVISource("video.avi", pixel_type="yuy2", fourCC="CDVC").

so what is the difference between this bug and the chroma upsampling bug present in the panasonic and microsoft decoders??? (for which you must use the line FixBrokenChromaUpsampling() in avisynth)

and what is the famous 'Chroma Upsamping Error' that wilbert mentions? how is this different from the chroma upsampling problems in the codecs i mentioned above?

[FredThompson]

The first post also compares outdated builds of codecs. It really should be edited or a new "first post" inserted with accurate, concise information and the remainder of this thread left as discussion. The MainConcept codec, as an example, has had four releases since version 2.04: 2.1.13.0, 2.3.1, 2.4.4, 2.4.16.

[Wilbert]

and what is the famous 'Chroma Upsamping Error' that wilbert mentions? how is this different from the chroma upsampling problems in the codecs i mentioned above?

http://www.avisynth.org/Sampling

i understand the canopus dv codec has this "chroma upsampling bug" that causes it to duplicate chroma lines when rendering NTSC DV (4:1:1) to YUY2 colorspace (4:2:2). and this bug can supposedly be corected in avisynth by adding Reinterpolate411() after AVISource("video.avi", pixel_type="yuy2", fourCC="CDVC").

Yup. It duplicates chroma for PAL too. (I wouldn't call it a bug though, you just get better quality when interpolating.)

so what is the difference between this bug and the chroma upsampling bug present in the panasonic and microsoft decoders???

MS DV codec upsamples in the following way:
http://www.avisynth.org/FixBrokenChromaUpsampling

The panasonic codec upsamples correctly.

Of course i agree with Fred though. We should also test the latest versions of the codecs for this.

[FredThompson]

Originally Posted by Wilbert

We should also test the latest versions of the codecs for this.

Given DV is all i-frames, how about a small set of samples in NTSC and PAL DV for testing? 5 frames, maybe less, should be enough.

The best option, I think, would be very high quality lossless frames which could then be used to test encoder and decoder. AFAIK, there is no freely-available perfect reference codec. The challenge will be obtaining proven "proper" source DV frames to test decoding. Even so, it should be remembered that DV devices do their own encoding so even a "perfect" decode could look like junk if the source is a bad encode.

The PAL frame scharfis_brain posted at http://forum.doom9.org/showthread.php?threadid=82787 should be a good sample.

I have the FlyVideo original capture of the opening Star Wars sequence used for the screenshots at http://www.geocities.com/xesdeeni200...parison-9x.PNG

[Wilbert]

I will open a new thread tomorrow to make a proposal

[Fizick]

The new thread is:
"DV decoder differences - update"
http://forum.doom9.org/showthread.php?t=98847

[mrajan]

Apple's DV codec does shift gamma when converted to RGB. It does this so that when displayed on a Mac computer screen, it looks more like it would on a TV or PC, which use similar screen gammas.

This gamma shift not only occurs wen the Apple DV codec is being decompressed for display on an RGB monitor but also when it is converted to an RGB format. Plus an RGB file converted to Apple DV would have a gamma shift as well.

I have not mixed Apple DV with other DV codecs, but it may be that the gamma shift would only be on the monitor screen and would not affect the actualy output to tape or MPEG2, etc. This should be easy enough to test.
Bob_Hudson is offline Reply With Quote

[moon1234]

Originally Posted by mrajan

Apple's DV codec does shift gamma when converted to RGB. It does this so that when displayed on a Mac computer screen, it looks more like it would on a TV or PC, which use similar screen gammas.

This gamma shift not only occurs wen the Apple DV codec is being decompressed for display on an RGB monitor but also when it is converted to an RGB format. Plus an RGB file converted to Apple DV would have a gamma shift as well.

I have not mixed Apple DV with other DV codecs, but it may be that the gamma shift would only be on the monitor screen and would not affect the actualy output to tape or MPEG2, etc. This should be easy enough to test.
Bob_Hudson is offline Reply With Quote

You responded to a 5 year old thread? Wow. Macs were not part of the consideration at that time. The problem WAS with decoded video that was being processed by Avisynth plugins or other video decoding programs. This needed to be corrected to maintain proper gamma.