DV decoder differences

[ScrollLock]

Hi folks,

since I recently purchased a DV device, I played around with various DV decoders. While I initially thought that they will all deliver the same result, I was surprised to find out that there is quite some significant difference between the decoders.


Canopus DV Codec V1.00

This codec uses the FourCC "cdvc", so before the system will use it you have to change the FourCC of the AVI file with a tool like AviC supplied with the XviD codec (default FourCC for DV is "dvsd").

Out of all DV codecs, the Canopus decoder does not seem to apply any sharpening of the decoded image (which is good in my opinion). It supports YUV2 and RGB color space.

Watch out though, when the Canopus decoder performs the RGB conversion it seems to use a luminance range of 16-235 instead of 0-255 used normally for computers.

RGB: http://mywebpage.netscape.com/wlopensource/TestSignal_Canopus_RGB.png [616 KB]
YUV2: http://mywebpage.netscape.com/wlopensource/TestSignal_Canopus_YUV2.png [557 KB]

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".

RBG with bug: http://mywebpage.netscape.com/wlopensource/JW_Canopus_RGB.png [717 KB]
YUV2 with bug: http://mywebpage.netscape.com/wlopensource/JW_Canopus_YUV2.png [776 KB]
YUV2 fixed: http://mywebpage.netscape.com/wlopensource/JW_Canopus_YUV2_fixed.png [764 KB]


MainConcept DV Codec Demo V2.0.4

The MainConcept decoder supports both YUV2 and RGB. Unfortunately out of the 3 decoders it performs the most sharpening, which increases the noise level. In both RGB and YUV2 modes it uses a luminance range of 0-255.

RGB: http://mywebpage.netscape.com/wlopensource/TestSignal_MainConcept_RGB.png [743 KB]
YUV2: http://mywebpage.netscape.com/wlopensource/TestSignal_MainConcept_YUV2.png [716 KB]

The MainConcept decoder does not have the chroma upsampling bug:

RGB: http://mywebpage.netscape.com/wlopensource/JW_MainConcept_RGB.png [768 KB]
YUV2: http://mywebpage.netscape.com/wlopensource/JW_MainConcept_YUV2.png [824 KB]


Panasonic DV decoder (version unknown)

The Panasonic decoder supports RGB color space only. It sharpens less than the MainConcept decoder but more than the Canopus. The luminance range is 0-255.

RGB: http://mywebpage.netscape.com/wlopensource/TestSignal_Panasonic_RGB.png [664 KB]

The Panasonic decoder does not have the chroma upsampling bug:

RGB: http://mywebpage.netscape.com/wlopensource/JW_Panasonic_RGB.png [734 KB]


My conclusion:
For RBG color space (e.g. for VirtualDub) the Panasonic DV decoder is the preferred choice. The Canopus decoder can't be used for that application due to it's chroma upsampling bug, and is also not preferred due to the reduced luminance range.
For YUV2 (e.g. AVISynth) I use the Canopus decoder and use the "FixBrokenChromaUpsampling" function to correct it's bug.
The MainConcept decoder applies too much sharpening for my taste, but if your source is noise-free than this decoder might be your decoder of choice as it supports both YUV2 and RGB, and does not suffer from the chroma upsampling bug.


yours truely, ScrollLock


Addendum: measuring method
All screenshots were taken from the same frame of the same DV file. The source files, which were capture from cable TV in Singapore (PAL), can be found at:
Test signal: http://mywebpage.netscape.com/wlopensource/TestSignal.avi [308 KB] (2nd frame was used)
Chroma bug check: http://mywebpage.netscape.com/wlopensource/JW_Frame3300-3310.avi [604 KB] (4th frame was used)

For RGB decoding the files were directly opened in VirtualDub. For YUV2 the files were passed through AviSynth and then into VirtualDub.

No processing was done for the Test Signal samples. For the chroma bug samples the source was deinterlaced. For RGB the VirtualDub filter "deinterlace - area based" was used. "Blend instead of interpolate" was turned off, Threshold=27, Edge detect=25. For YUV2 the AVISynth filter GreedyHMA(0,0,1,0,0,0,0,0) was used.
NOTE: don't compare the image quality between RGB and YUV2 as it is influenced by the different deinterlace algorithms!

[taudule]

Fichtre ! (as we say in french), astonishing !
It's a long time since i havn't checked that chain link, and i thought i was OK using mainconcept...
As i want to test that, perhaps you could you help me:
The DV compression is done by the camcorder, and OHCI capturing is just a file transfert.
So can i change my captured avi files from one coded to an other, without re-writing or re-capturing ? (tests purpose, as i can't recapture right now).

.

[ScrollLock]

Originally posted by taudule

The DV compression is done by the camcorder, and OHCI capturing is just a file transfert.
So can i change my captured avi files from one coded to an other, without re-writing or re-capturing ?

Absolutely! The encoding is not in your influence at all, it is done in hardware in your camcorder as you wrote correctly. "Capturing" from a DV camcorder is basically only dumping the content received from the camcorder via FireWire into an AVI file on your harddisk.

You can install the Canopus decoder in parallel with either the MainConcept or the Panasonic decoder as it uses a different "FourCC" code. But in order to use it, you have to change the FourCC of your captures from "dvsd" (= the standard in Windows, used by Pana and MainConcept) to "cdvc" (= Canopus proprietary). This can be done with various tools, e.g. with "AviC" supplied with the XviD MPEG4 codec.
Note that this only changes a few characters in the AVI file, it does not alter the actual A/V-data in any way.

I think that in order to switch between the Pana and the MainConcept, you have to uninstall the current one before installing the other, but maybe there are tools that allow you to select which decoder to be used for a given FourCC. Anybody knowledgable of such a tool?

salut, ScrollLock

[taudule]

Thank you for your quick answer. i'll do some testing this WE.
I just made some research and found here :
http://www.canopus.com/US/products/DV_file_converter/pm_dv_file_converter.asp
the (free) tool to convert the streams.
It rewrites the avi, but i suspect it is not necessary as you state; changing "dvsd" to "CDVC" in the avi header makes it seen as "canopus software DV" in the file properties box.
How can i be sure that when outputed to the screen, the avi is really uncompressed by canopus?
.

[bira]

First thing: amazing! Thanks!

Second thing: How can I prevent MS decoder from being used?

bira

[ScrollLock]

Originally posted by taudule

How can i be sure that when outputed to the screen, the avi is really uncompressed by canopus?

Open the file in VirtualDub, go to the file menu and select "File Information". The dialog that comes up shows you the used compressor.

Originally posted by bira

How can I prevent MS decoder from being used?

No idea. Actually, I don't know at all how to use the MS DV decoder in the first place in AVISynth or VirtualDub. Even when I use "DirectShowSource" in AVISynth it used the Canopus/MainConcept/Panasonic decoder (depending on what was installed and what the FourCC said).
Hopefully someone else will give us a satisfying answer.
BTW: according to the AVISynth documentation, the MS codec also suffers from the chroma upsampling bug.

kind regards, ScrollLock

[taudule]

MainConcept DV Codec Demo V2.0.4

The MainConcept decoder supports both YUV2 and RGB. Unfortunately out of the 3 decoders it performs the most sharpening, which increases the noise level. In both RGB and YUV2 modes it uses a luminance range of 0-255.

You are perfectly right! I just finished viewing side by side with 2 virtualdubs the same DV source, one decoded by mainconcept, the other by canopus (via avisynth script), and the result is noticeably better with canopus (less noise). I'm now going to test encoding, but it should improve... I'm really surprised nobody noticed that before (i've read so many discussion about DV codecs already!).

BTW, changing the dvsd for CDVC in the avi header is enough to enable decoding by canopus, provided you have the canopus codec installed, of course (i use W2000)
.

[bira]

Even when I use "DirectShowSource" in AVISynth it used the Canopus/MainConcept/Panasonic decoder (depending on what was installed and what the FourCC said).

Does that mean that if any other dv decoder is installed, MS decoder will never be used in any software?

[ScrollLock]

Originally posted by bira


Does that mean that if any other dv decoder is installed, MS decoder will never be used in any software?

I have no idea, to be honest. It was just my (brief) observation, and possibly I did something wrong. Or maybe the MS DV codec uses another FourCC?

regards, ScrollLock

[Bandung]

What I've seen is that VirtualDub can not call/see the Microsoft codec because VirtualDub uses vfw rather than wdm screen drivers.

I have another programme called Multiquence which will see the Microsoft wdm based codec and use it. It turns out that Ulead's Video Studio also uses the MS codec. Mainconcept's codec is vfw based. So as long as you are using VirtualDub, you will not have to deal with the MS codec. But if you decide to used Graphedit, then you can and wil end up calling the MS codec.

[bb]

I guess the MS codec will be used if you frameserver through AviSynth using the "DirectShowSource" command.

bb

[kayman]

great thread scrollock , after reading and doing test i now how to get my dv avis to use the canpos decoder and i love it , its so much better then mainconpt

congrats

kayman

[igor140]

Great thread, thanks for your enlightening research, scrollock.

Maybe I can help with a link to a neat little codec swapping program:
Try VCSwap, which can be downloaded from
http://members.ams.chello.nl/p.bekke/

[Bandung]

This VC Codec swapper? A great find! Thank you.

[taudule]

I just found that link in my archives, while making some dust clean :
http://home.hetnet.nl/~jackwburger/index.html

Happy codec swapping
O.

[Faceman101]

While I am not 100% sure on this, but I remember reading about DV codecs and that Mainconcept and Canopus are different but Sony/Panasonic/Microsoft were actually the same. They differ by nothing that affects output, they put out the same output (S/P/M), while Canopus and Mainconcept do something else to quality.

If anyone knows more or heard of this, more info would be nice (besides what ScrollLock has mentioned from experience, I mean more of a technical side of it).

[Arky]

Nice thread ScrollLock - ever done any tests with Fast's DV codec? (this is used in Pinnacle Edition, because the program is actually Fast DV Studio)

Canopus attempted to do a demolition job on the competitions' hardware cards by illustrating generational codec losses, BTW.


Arky ;o)

[yg1968]

Just to clarify a few points: installing a DV codec is only necessary for programs that only use video for windows (vfw) and type 2 avi DV files such as Vdub. If your program uses directshow (included in Direct X) and type 1 DV avi, it will automatically use the built-in MS DV codec. Vdub is a vfw only program. For vdub, a DV codec is necessary and you must use type 2 DV avi files. More and more programs are using directshow. So installing a DV codec is becoming less and less necessary (although it doesn't hurt to install one in case that you wish to use it for a type 2 DV avi file).

Microsoft explains all of this in the following text:

http://www.microsoft.com/hwdev/tech/stream/vidcap/dvavi.asp

Adam Wilt also explains this on his website:

http://www.adamwilt.com/DV-FAQ-editing.html#NLE

See also this website:

http://www.well.com/user/richardl/SilverListFrameSet.html

In a simplified version, the Microsoft article states that a type 2 DV avi file is vfw compatible and that a type 1 DV avi file is not vfw compatible. Directshow can read both type 1 and type 2 DV avi files. In other words, a vfw only program (such as vdub) will not be able to read type 1 files. It will be able to read a type 2 file DV avi file if a DV codec is installed. A program that uses directshow (for example, Premiere 6.5 or Ulead VS 7.0) will not need a DV codec for a type 1 or a type 2 DV file (but a DV codec can be used for a type 2 DV avi file).

On an unrelated point, the Canopus DV codec only gets used for Canopus software (or if you convert the DV avi file to a Canopus DV file). For this reason, I have never actually used it. In order for vdub to accept type 2 DV avi files, I have installed the Panasonic DV codec.

Interestingly, it seems that Panasonic is making the MS DV codec that is built in directshow. See this link:
http://www.microsoft.com/presspass/press/1997/Apr97/MSMEIpr.asp

P.S. Incidentally, you can use the following freeware programs to capture in type 2 DV avi: DVapp or DVIO.

[bb]

Originally posted by yg1968
Vdub is a vfw only program. For vdub, a DV codec is necessary and you must use type 2 DV avi files.
Yes, indeed, VirtualDub is a VfW based program. But despite what you say it can open DV type-1 files. You'll get a warning, and you can't process the audio, but for video processing only simply open the type-1 file, ignore the warning, and use it just like any other AVI. You need a VfW DV codec installed, though.

By the way: it seems that not all type-1 and type-2 capable video editors work equally well with either format. E.g. Ulead's Media Studio Pro 6.5 is quite buggy when using type-2, but it seems to work fine with type-1. You'll experience the difference when using more complicated transitions / overlays.

bb

[DDogg]

bb, on that note I would add that Vegas also has trouble with longer and more complicated output from the DV1 type files generated by WMM2. Short and simple ones seems ok. Using the free file convertor from Canopus and converting the file to MS DV2 seems to take care of the problem.

[FredThompson]

The full version of MainConcept's decoder is 2.1.13.0, at least, that's what they sent me last week.

Seems like a few iterrations of change have happened to the codec.

I can make screen grabs. Thing is, without knowing which decoder settings were enabled when the 2.04 demo version was used it's not a proper comparison.

I'm also wondering how you determined the MainConcept is sharpening instead of the Panasonic codec softening during decoding.

[IanD]

Originally posted by ScrollLock
For RBG color space (e.g. for VirtualDub) the Panasonic DV decoder is the preferred choice. The Canopus decoder can't be used for that application due to it's chroma upsampling bug, and is also not preferred due to the reduced luminance range.
For YUV2 (e.g. AVISynth) I use the Canopus decoder and use the "FixBrokenChromaUpsampling" function to correct it's bug.

Based on your comparison and the desire to not overly sharpen my ADVC-100 NTSC 4:1:1 DV capture, I have only tested the Canopus and Panasonic decoders (using Avisynth to Virtualdub).

However, I have noticed a strange artifact with the Canopus software decoder on areas of highly saturated colour (particularly on a dark background): the areas appear 'crosshatched'. This effect is not nearly as pronounced using the Panasonic software decoder and non-existent in a huffyuv capture of the same source.

By enlarging a small section of the offending area in the 3 different images, so that the individual pixels are readily visible, it is apparent that the Canopus decoder is interpolating to create a definite 4x4 block type effect, the Panasonic decoder is creating more of a 2x2 block effect and the huffyuv is a 1x1 pixel mapping. It is the 4x4 block effect that makes the 'crosshatch' very noticeable along the edges of saturated objects.

Furthermore, the Canopus decoded image is brighter than the others and exhibits a multicolour mosaic effect, especially noticeable on near black areas.

Curiously the Canopus decoded image appears overall more visually appealing and 'cleaner' than the Panasonic decoding, although softer, apart from the crosshatch on saturated colours.

Initially I thought the crosshatching was due to the chroma upsampling bug, but applying the FixBrokenChromaUpsampling() function in Avisynth actually makes the image look worse, with combing artifacts and doesn't fix the crosshatch problem.

I suspect the chroma upsampling bug referred to is actually a problem with 4:2:0 codings, due to the interpolation across interlaced fields, and the FixBrokenChromaUpsampling() function is designed to tackle that only. For 4:1:1 codings of NTSC, chroma interpolation is only necessary in the horizontal direction, as there is a sample on every scanline of every field.

Does anyone have an explanation and workaround for the Canopus software decoder 'crosshatching bug' on 4:1:1 codings, particularly noticeable in areas of saturated colour on dark backgrounds?

I would prefer to use the Canopus decoder for its cleaner image, but cannot if it is subject to these saturated artifacts.

Ian

[FredThompson]

The near-black problem isn't unique to any one codec. It's an aspect of the analog capture process.

[bb]

I guess the different block sizes you experienced come from different decisions of the codecs on where to use higher or lower quantizers, respectively.

bb

[IanD]

Originally posted by FredThompson
The near-black problem isn't unique to any one codec. It's an aspect of the analog capture process.
It appears to be emphasized by the Canopus DV software decoder as the Panasonic software decoder doesn't exhibit the effect anywhere near as badly.

I reckon the Canopus DV software decoder is broken for 4:1:1 chroma (or at least the freely available one).

Ian

[yg1968]

See this related thread:

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

[FredThompson]

Apparently, the Panasonic codec screws up over multiple-generations:

http://www.marumo.ne.jp/gvdvc/codec.html

Babelfish: http://babelfish.altavista.com/babelfish/urltrurl?tt=url&url=http%3A%2F%2Fwww.marumo.ne.jp%2Fgvdvc%2Fcodec.html&lp=ja_en

[GunX]

I think Panasonic DV messes up the virtualdub and virtualdubmod.
After restart from the installation, on WinXP, with the attempt to open a DivX5 file, VDub goes crazy and tries to open it with Panasonic DV codec !

Of course I get an error, but the fourcc code is right. What it's happening ? Same error after reinstalling Windows from scratch !

http://www.strike.home.ro/problem.JPG

[bb]

No problem here. Maybe something wrong with your REG file?

bb

[GunX]

actually, it's a inf file (previous version ?)
I'll try the reg install version

[bb]

You can download the codec together with the REG file from the "Links" sticky thread.

bb

[moon1234]

I have also done the testing and contrary to what some have stated above I have found the following:

All captures done with Canopus ADVC-1394

1. There is a chroma upsampling bug with both 4:1:1 and 4:2:0 material. The fix as stated is to use the fixbrokenchromaupsampling in avisynth.

2. 4:2:0 material if captured from analog source has most likely already had its dynamic range compressed to match your TV set. Meaning you will see your blacks and whites clipped (TV Safe Range). You can somewhat correct for this in avisynth by using the levels command 16 on the low end and 240 on the high end. You still loose a little though. You can check to see if the dynamic range is compressed by frameserving the file using the Canopus codec to Virtualdub. In Virtualdub use the histogram filter to display the files dynamic range. I bet that on almost all of your tv captures the dynamic range has been compressed. This dynamic range compression is sometimes referred to to as "Fog" or "Haze" by some less experienced users.

3. Changing the FourCC header is all that is needed to use a different decoding codec. The player looks at this "Header" information when it opens the file. That is how it knows which codec to use to decode. Again there is no need to uninstall codecs to test as some have suggested.

4. When editing you really need to uncheck "Always recompress" if using premier or similar command in your favorite editor. If you do not do this then the copied DV stream will be compressed again using the codec that is assigned the DVSD FourCC. Why compress an already compressed stream? If you MUST tinker with the stream then save to HuffYUV and choose "Convert to YUY2" so there is no loss in quality. Then you can open, save, and edit all you want without constantly degrading your signal.

NOTE:
If you are editing in Premier or other RGB editor multiple times DO NOT convert to YUY2 until you are FINISHED editing. Otherwise you will be throwing away color information with each save.

(Please don't whine about hard drive space. HD's and a Promise fast track are cheap now. You should have a large array if you are doing any amount of video work.)

5. The Canopus codec is not broken from a 4:1:1 standpoint. Why in the world would they release a codec designed to decompress DV, which is 4:1:1, that had such an obvious oversight? The answer, they didn't. The chroma upsampling is an attempt to restore some of the lost chroma information that is inherent in DV capture from a DV SOURCE.

Why do you think all major networks have switched to 4:2:2 MPEG2 DVB Studio color on all of their sat feeds? They appreciate the increased chrominance information. The problem with the chroma upsampling comes in when you capture a 4:2:0 source as the chrominance information is already maxed out so to speak and you are then amplifying it again.

[FredThompson]

Good post.

MainConcept also has a setting to pass full range.

NTSC DV is 4:1:1 which has a colorspace disconnect with 4:2:0 source. Two good solutions are DVHelper for VirtualDub or ReInterpolate411 for AviSynth. Both are attempts to "resize" colorspace to 4:2:2 and reduce chroma bleed.

[row92]

My question is rather easy: can anyone tell me what DV codec works on progressive films (99% of DVDs are progressive).

In order to edit some film sequences, I use DV2AVI, then MPEG2DEC3 and Virtual Dub to recompress it in DV format (with MainConcept). Afterwardsa, I convert it back to MPEG-2 for DVD.

I need the better quality and I guess MainConcept interlaces my decoded frames from the DVD.

Do you know a DV codec able to handle progressive frames ?*

[scharfis_brain]

I wouldn't save progressive Video with a CoDec that only handles interlaced Video.

It will destroy / degrade the Color information.

progressive YV12 (2x2 Luma-Pixel per Chroma) will be converted to interlaced YV12. This results in (2x4 Pixels per Chroma Sample)...

[moon1234]

The easiest way of editing this material is to get it into a container that is easily editable. Unfortunalty the one I am going to suggest is also very disk space heavy. DV will work, but again why compress an already compressed signal? It will then be decompressed to edit it (Probably converted to RGB) recompressed when saved (If you don't frameserve it) then feed to an MPEG2 compressor which will compress the image again and convert the color spave to YV12. So lets add that up. The compressed MPEG2 signal will be recompressed 3 times MPEG2>DV>RGB>MPEG2 (DV is lossy. So each save throws away info.) and go three possibly 4 color space conversions YV12>DV>RGB>YV12.

If it were me, I would frameserve the DVD material using Avisynth to virtualdub. Using fast recompress under video options in Virtualdub, I would then save the file using the HuffYUV codec. Make sure that you configure HuffYUV's field detection resolution to 576. Otherwise you will save your progressive information as interlaced. (Provided you either deinterlaced or inverse telecined it first) Also make sure that HuffYUV is set to save the clips in YUY2 format and not RGB.

Since I don't know of any editing programs, other than Avisynth and VirtualdubMod, that work in the YV12 colorspace you will wind up working in either YUY2 or RGB. Any conversion to RGB and back is very time intensive. You also loose chrominance information twice just to edit once!

If you just want to sharpen some video or cut out a few scenes, just do the whole process in Avisynth. You will save yourself a ton of time, disk space, color space conversions, recompressions and numerous other steps.

-Moon1234

[Paul Langemeijer]

i dont know for sure, but dv video is not split into fields.
a full ress picture is split into groups of 8x8 pixel blocks.
the codec then decides for each 8x8 block if it'l use a 8x8 dct (non interlaced block) or 2 8x4 dct (interlaced block).

at least if the codec uses it. the dv format does support it. just do a google search.

[bb]

DV video is encoded as frames, but most of the time DV is interlaced, which means that every other line is taken from a different time (1/50s difference for PAL). When speaking about "field based" DV, the talk is about the signal, not the encoding. Even in MPEG-2 interlaced video is usually encoded as frames (using alternate scan, if done correctly).

bb

[Abaddon666]

I decode my DV-Files via ffdshow/libavcodec. This delivers, IMHO, the best quality. The DV-fourcc-code must be "dvsd" and in your ffdshow configuration->codecs you must set DV to "libavcodec". Then use "directshowsource("your_video.avi",seek=true)" in avisynth and decide for yourself.

greetz,

Abaddon666

[State of Mind]

Hello, this is my first time posting on this particular forum. I use WinDV to upload my DV files onto my PC. I use VirtualDub (newest version) to edit/cut out unwanted parts. I use TMPGEnc Plus (Newest version) to convert to MPEG-2. I have TMPGEnc DVD Author (Newest version) to author and burn a DVD but haven't done my first one yet. This however, is irrelevant to what my concern is. I am wondering what the best DV Codec is to use for the best DV quality with minimum or no de-interlacing artifacts? I have a feeling someone is going to tell me to start using AVISynth. I do not know what RGB or YUV2 or whatever you guys call those are. What exactly is noise, also? Does my Panasonic MiniDV PalmCorder PV-DV953 (http://www.panasonic.ca/English/audiovideo/video/palmcorder/pvdv953.asp) have noise? Can I completely remove the noise from the file? Can I de-interlace without it resulting in any artifacts? I am extremely curious and would be very appreciative of responses from anyone knowledgeable about what I am concerned about. I suppose I am a newbie in some ways but an intermediate in other ways, but I hope after learning things from other users, I can become an intermediate and hopefully an expert. This is almost starting to sound like a resume, lol. Thanks in advance!
Jeremy

[FredThompson]

NTSC DV? Use trbarry's AviSynth filter to make a better MPEG2.

noise with DV is usually from cheap CCDs or artifacts due to 4:1:1 color of NTSC DV. Deinterlacing will always throw away half the temporal information There's no good reason to deinterlace unless you want to go back to a film source.

[bb]

Originally posted by FredThompson
[...]noise with DV is usually from cheap CCDs or artifacts due to 4:1:1 color of NTSC DV.[...]
That's true, but noise typically occurs in low-light conditions, no matter how good your CCD is. Low-light in this case refers to the amount of light the CCDs can capture, so to say "how much light gets inside the camcorder". Thus good and big object lenses can make lower-noise DV video than small ones with the same (low) light outside.

bb

[gavo]

You say that the maincopect is the worse because of the sharpen although I find it safer because of less bugs, What if you use smoothing filters in avistyn would that average it out to about the same?

[moon1234]

Originally posted by FredThompson
NTSC DV? Use trbarry's AviSynth filter to make a better MPEG2.

noise with DV is usually from cheap CCDs or artifacts due to 4:1:1 color of NTSC DV. Deinterlacing will always throw away half the temporal information There's no good reason to deinterlace unless you want to go back to a film source.

Unless your ultimate destination is PC video such as a training seminar, etc.

[moon1234]

Originally posted by bb
That's true, but noise typically occurs in low-light conditions, no matter how good your CCD is. Low-light in this case refers to the amount of light the CCDs can capture, so to say "how much light gets inside the camcorder". Thus good and big object lenses can make lower-noise DV video than small ones with the same (low) light outside.

bb

With a good CCD sensor there should be virtually no noise in the absence of light. Put the lens cover on any consumer DV camera (Regardless of lens size) and film about ten seconds. Then bring that into your PC and examine the noise pattern.

Then do the same thing with a prosumer or prosessional 3CCD camera such as the Sony VX2100. You will see virtually no noise even in the complete absence of light.

More noise in the origional is due to inferior CCDs, as you stated in your post. Low light has no correlation to the level of noise. High quality CCDs can record virtually noise free video even in the complete absense of light.

You really do get what you pay for with CCD technology. If you really want clean, professional looking video you need to go for prosumer cameras and not the over the counter consumer models. How replaceable are your kids first years? You will never get them back, so why skimp on the technology to remember them?

Get a cheaper car, you can always upgrade. You will never get those precious moments back. How many of us look at photos taken of our families ancestors around the turn of the 20th century (1880-1910) and really appreciate them? How many of those photos were taken with an off the shelf camera? Virtually none of them were. The photos were taken in studios or outside with professional equipment of the time. The same rules should apply today.

[SimonSez07]

@Abaddon666

i use ffdshow to decode my dv avi's as you do, but i have found that with the newer versions of the package, you do not need to use DirectShowSource in AVISynth.

ffdshow can now decode with vfw, but you must go into "VFW Configuration" and under decoder, set DV from "disabled" to "libavcodec".

now you can decode dv type-2 directly from within vdub or cce or whatever without installing any other codec. and i think will decode to all (yv12, yuv2, and rgb) colorspaces

it would be great if ffdshow vfw decoder could be put in this comparison with panasonic, mainconcept, and canopus

[makoto916]

Has anyone had the opportunity to review the VFW DV Codec from Matrox? It ships with all of their RTX DV boards. The Codec doesn't need the board to work but unfortunately, while the codec is free, it is only available to download if you are a registered RTX user.

Nevertheless, has anyone done any testing with it? If not, if someone would share with me your procedure for testing, I'd be happy to supply a test sample.

I think the codec is worth checking out. I've been using it for a couple of years now and have found it to be superior to Mainconcept and Canopus, but I'm hardly an expert and would rather the experts here be the judge.

EDIT:

Actually posting this got me thinking so I did some of my own tests using rather unsophisticated means. I took the DV Stress Test picture from adamwilt.com (http://www.adamwilt.com/DVS-orig.JPG) and threw it into Premiere 1.5 and encoded a 15 frame video into Microsoft DV, Matrox DV, and Matrox DVCPRO50.

Here are the links to the AVIs: Matrox DV (http://www.blainehelmick.com/hosted/DVTest/MatroxDV_Test.avi), Matrox DVCPRO50 (http://www.blainehelmick.com/hosted/DVTest/MatroxDVCPro50_Test.avi), and Microsoft DV (http://www.blainehelmick.com/hosted/DVTest/MSDV_Test.avi). Note that I did these tests using the Matrox VFW DV and DVCPRO50 Codec and not on the system with the RTX100 board so that the tests weren't influenced by the hardware.

I don't know how to interpret the results. Just by loading the resulting AVI into Virtual Dub, the Matrox DV codec clearly handles solid color better as there are very few artificats in the solid areas. However, the Chroma Only section is absolutely terrible. You can at least read it with the MSDV Codec, but with the Matrox codec its just garbage. It's almost as if the MS Codec is anti-aliasing where the Matrox is not. But again I really don't know what I'm looking at so this is just casual observation.

The DVCPRO50 Codec on the otherhand is quite good, aside from some slight pixelization in the chroma text and hard curves.

Also, I don't know if Premiere had any influence on this test. Any insight is appreciated.

[SimonSez07]

@ makoto916 -

what is DVCPRO50? and what is the diference between that and the other matrox codec u tested. and how do you encode with microsoft dv. i do belive microsoft dv is NOT a codec but just a decoder filter.

it was a good idea to test more codes by the way. it actually might be interesting to test these codecs in their ability to decode dv also, and post the results of which is fastest, decodes to all three colorspaces without problems, and has the highest quality.

[makoto916]

In a nutshel, DVCPRO is an alternate DV methodology and DVCPRO50 is the "profesional" version with double the bitrate of standard DV (50mbps instead of 25). I believe JVC is one of the big DVCPRO pushers.

The codec I tested was Matrox's DV and DVCPRO codecs. I tested the encoding side of them, not the decoding, and matched them up against MS DV to see what was better. From my perspective it's hard to tell since I'm not as skilled in video as many of the others here, hence the reason for my post.

As for encoding in MS DV it is not a VFW codec in that you can't use it with any application. Only applications that support DirectShow will support this, but you can indeed encode into it. I hope that someday VirtualDub will support encoding into MS DV as well as other DirectShow codecs.

[FredThompson]

http://home.mindspring.com/~fredthompson/PAL%20DV%20junk.png

Enlarge and look at the upper left yellow arm of the robot.

[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

[sunshine99]

Thanks for your enlightening research, scrollock.:helpful: