DV decoder differences

[makoto916]

It certainly appears that the newer version handles saturated reds better. Theres less of a "patterned" look to it.

[WorBry]

Regarding the Matrox codecs - see my initial observations with DV/DVCAM (vfw version) in the following thread (11th post):

http://forum.doom9.org/showthread.php?s=&threadid=86422

Please dont give me a hard time if my "laymans" theoretical assumptions about color space conversion are off. At the end of the day, I'm just trying to get the best quality video. I havent tried the DVCPRO format yet.

I'd really appreciate it if someone could advise, when converting to DVD (for TV playback), what color adjustment method to use in TMPGenc Express to properly correct for the luminance shift "haze" that arises when using the Sony DV codec as decompressor. My experiences with that codec are noted in the same thread.

Cheers.

[Steve56]

I did also test the ffdshow livavcodec YV12 decoding versus DirectShow YUY2 decoding, but I think the YV12 decoded image is not as good (seems to have blurred chroma between the interlaced lines?!).

QuickTime DV -> DirectShowSource -> libavcodecYV12 -> VDubMod:
http://www.macologie.de/dv_libavcodecYV12.jpg

QuickTime DV -> DirectShowSource -> YUY2 -> VDubMod:
http://www.macologie.de/dv_directshowYUY2.jpg

BTW, what made me wonder in the first was, that I could open the QuickTime DV streams directly with DirectShowSource in AviSynth, that didn't work in the past (I used DV File Converter then), maybe because of a present NeroVision Express QuickTime/DirectShow layer?

Steve56

[makoto916]

@WorBry - Actually I have the opposite happen here with Field order. The Matrox NTSC codec forces everything to Bottom Filed first and it's quite the pain when using NTSC DVDs which tend to be TFF. I wish I knew a way to have AVISynth detect field order as my output needs to be interlaced and not progressive for what I do with it.

@Steve56 - I don't know if Nero installs a DirectShow decoder for Quicktime, but I know that with FFDShow and 3IVX installed you can sucessfully decode QuicktimeDV via DirectShowSource in AVISynth. It actually works remarkably well.

[WorBry]

Makoto.

Here's an abstract from the KernelDeint AVS filter Info file that explains how to determine the field order:

"KernelDeint() takes the following named parameters:

order (0-1, default none!) This parameter defines the field order of the clip. It is very important to set this correctly. Use order=0 for bottom field first (bff). Use order=1 for top field first (tff). You must specify order; DGBob throws an exception if you omit this parameter.

It is essential to set the field order properly for correct rendering. Because setting it correctly is so important, you are strongly encouraged not to make assumptions about the field order of a clip, but rather to verify the field order using the following procedure.

To determine the field order, make an Avisynth script that serves the raw clip without any processing. If it were an AVI, then just AviSource() would be used. For our examples, we'll use AviSource(). Add a script line to separate the fields using top field first, as follows:

AviSource("your_clip.avi")
AssumeTFF().SeparateFields()

Now serve the script into VirtualDub and find an area with motion. Single step forward through the motion. Note whether the motion progresses always forward as it should, or whether it jumps back and forth as it proceeds. For example, if the field order is wrong, an object moving steadily from left to right would move right, then jump back left a little, then move right again, etc. If the field order is correct, it moves steadily to the right.

If the motion is correct with AssumeTFF().SeparateFields(), then your field order is top field first and you must set order=1. If the motion is incorrect, then your field order is bottom field first and you must set order=0. If you are want to double check things, you can use AssumeBFF.SeparateFields() to check correct operation for bottom field first."

Hope that helps.

[makoto916]

WorBry, thank you for the information. It is most helpful.

[WorBry]

Makoto916,

You're welcome.

I agree, its very strange that the Matrox DV/DVCAM codec outputs PAL as TFF and NTSC as BFF, as you say.

For my normal purposes I'm only using Matrox codec as a decompressor. When capturing and editing, I usually disable Matrox and use the internal Type II DV encoder in Ulead Video Studio. I got into this habit when using the Sony DV codec. Even if not selected for smart-rendering the edited DV clip, merely having the Sony DV codec enabled would result in edited segments (transitions etc) that were lighter than the unedited portion. In fact, I would get the same result even if the entire clip was completely recompressed. I havent checked to see whether the Matrox codec does the same - probably not, since it does not appear to be subject to luminance shifts. But, like I, said its a habit, I've got into.

For interests sake, I've just re-encoded a few of my PAL DV clips with the Matrox codec to see what happens to the field order and sure enough - TFF again. I had some notion that maybe the codec reverses BFF to TFF on encoding and then back to BFF on decompression, but obviously not

BTW - various forum threads I've come across discussing the Matrox codec refer to advanced configuration settings. Do you know how to access these settings. The Windows version of the Matrox Digisuite codecs package that I downloaded doesnt seem to have any such options, at least when opened in the VirtualDub Compression codec library. Is this feature only available in Premiere or something ?

Cheers.

[makoto916]

I'm unaware of any advanced setting with the Matrox codec. I loaded up FilterManager just to see and there doesn't appear to be anything special for it.

Also under Premiere Pro 1.5 when you select the Matrox codec for export the "Configure" button greys out indicating there are no additional settings to tweak.

So your guess is as good as mine.

[Lycaon]

Originally posted by Steve56
ffdshow libavcodec YV12 decoding...is not as good (seems to have blurred chroma between the interlaced lines?!)

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.

Does anyone know of a decoder that decodes in the Native 4:1:1? It seems most all of them, including microsoft and Mainconcept only support 4:2:2 and require the FixBrokenChromaUpsampling.

[whiskey]

Ok guys so if i have panasonic miniDV camcorder i should use codecs from panasonic or u recommend other stuff ???

[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.php?p=693291#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]

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/xesdeeni2001/411Comparison-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]

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.