A small study of DV Codecs

[ulfschack]

I took some time to look at the differences between DV codecs. And the differences were indeed big! I know this has been done before (allthough not often enough IMHO). Here are the Codecs that I tried out together with some of the information I got via VirtualDub and avisynth's "info" (test clip framerate and color space).

1. Main Concept 2.1.0, 27 fps, YUY2
2. Sony DV 2.23, 22 fps, RGB24
3. Canopus 2.7(multi thread), 25 fps, YUY2
4. Panasonic 2.64, 27 fps, RGB24
5. Pinnacle DV25, 17fps, RGB32

When testing these Codecs there are unfortunately no "original" to compare to, since the raw DV file has to be interpeted somehow by a compatible Codec in the system. So I've been very careful not to mix any of the codecs. Also for those that had double fourCC (MC and Canopus also installed a CDVC) I made sure to use only the DVSD version which was what the other codecs seem to have. Here's what I did:

--------------------------------
a) Captured a DV to HD.
b) Installed 1-5 one at a time.
c) Loaded in VD and saved as Codec installed under b)
d) Before closing I also saved as uncompressed RGB and grabbed a nice frame as BMP for comparison
e) Loaded avi saved in c) and saved that one as uncompressed RGB as well (and got a BMP there too)
f) goto b)

So now I have, from each codec, one avi (xxx1st.avi) that is the product of one decoding (the kind of avi you get when frameserving from your NLE app) and another avi (xxx2nd.avi) that is a product of two decodings and one coding (the kind of avi you get when doing intermediate saves to HD before feeding it to CCE or similar). And also two BMPs.

Next I did a "subtract" in a avisynth script between xxx1st.avi and xxx2nd.avi to see the generational degradation in the Codecs. I saved a BMP of this for each codec.

I also did a "subtract" between Codecs amounting to 4+3+2+1=10 additional BMPs
--------------------------------

The findings:

It's impossible to show all 24 BMPs here on this forum, but if any kind soul would volounteer to host them for a while it would be much easier to understand the differences. I guess JPEG would suffice for the "subtracted" BMPs, but for the "real" frames DCT blocks could be confusing in this format. Till then you'll have to make do with my subjective description,


MC: Crisp and sharp. Nice colors. It would be my first choise if not for the enormous degradation in the second encode. There several segments of borderlines were completely blurred as if you'd smeared grease on the screen selectively. Only good for frameserving (if they haven't fixed this issue in the latest version that is). I suspect that some sharpening is done. The color space is converted to RGB32 from YUY2 when saving in VD.

Sony: The darkest of them all. I guess this could be fixed with some gamma/lumnance/color correction. It also has a haze of fog over it in comparison to panasonic and Main Concept (also fixable) ... kind of like an auto-level is needed. But not as much as Canopus and Pinnacle. The most interesting thing about this Codec is that it has almost no second generation degradation. At first I thought I'd made a misstake and saved the same BMP twice, but after a while I was able to make out subtle differences while changing back and forth in ACDsee. Intermediate saves with this Codec appearantly doesn't harm the quality of the video, which is good since that's the Codec I myself have been using for the last 2 years

Canopus: A lot like Sony but lighter. As mentioned in the "sony description" it has a somewhat of a fog cast over it. Maybe this is how the video should look like and maybe MC and panasonic has some kind of auto-level or color correction built in which could just as well be compensated for in avisynth or your NLE application ... I don't know ... kinda hard to tell without a nice original. This Codec has an option to expand RGB to 150% which didn't seem to make any difference when applied and converting color space in a special test run that I made. Curiously converting to YUY2 in avisynth with either option checked it came out with the same likeness in color and contrast as MC and panasonic only slightly more blurred. This is strange since it's allready in YUY2 ... go figure(?). The generational degradation (I'm gonna call it GD from now on, ok) was almost as small as that of sony's. Like for MC the color space is converted to RGB32 from YUY2 when saving in VD.

Panasonic: Almost identical to MC, but the GD was smaller, a great deal in fact, although not as good as sony's and Canopus'.

Pinnacele: Slow. The "haze of fog" on this one is more prominent than in any of the other Codecs. Colors are more washed out and it gets worse for second generation too ... by a whole notch ... almost as if it's gradually going to black-and-white eventually. There are not many signs of artifacts though (as in MC).


My choise: Well, not Main Concept or Pinnacle, so I guess I would go for either Canopus or Sony, with some reservation for the seemingly enhanced detail in Panasonic (it might be just noise, mind you ... very hard to tell actually) Sony never drops a frame while capturing (might be true for the others too, although I had problems with Adaptec's SoftDV (type-1 DirectShow) in my early years). Color and luminance correctable in either Avisynth or Vegas/Premiere. No GD to talk of.

Finally I have a question for any expert on the matter. How come I was able to direct-stream-copy a DV encoded (sony) avi using all available Codecs (the speed was the same for all... rougly 65 fps)? I thought that in order to do this you'd have to have the right Codec at hand. Appearantly all DV Codecs share the minimum of similarities required to do just this (just my guess).

I still have all the files on HD, so If I've missed anyhing vital (which I probably have) please feel free to ask and I'll try to assist best I can.


Cheers

[taudule]

Two things i'd like to say :

and another avi (xxx2nd.avi) that is a product of two decodings and one coding (the kind of avi you get when doing intermediate saves to HD

If you uncheck "recompression always" in premiere, or if you check "perform smartrender" in mediastudio, you get an intermediate file that should have not been touched by the NLE (the codec is only used to encode transitions). So you can have no generational degradation and no YUY2->RGB conversion at this point, if you wish.

About Canopus codec, the "fog effect" comes from the YUY2->RGB conversion, as stated by ScrollLock in the sticky thread, as it uses a luminance range of 16-235 instead of 0-255.
If you frameserve from premiere, to correct the levels, you can use :
ConvertToYUY2()
ColorYuv(levels="TV->PC")
in avisynth, but it involves two or three colorspace conversions (YUY2->RGB->YUY2, + YUY2->RGB if tmpGenc).
And if you want to mpeg2 encode note that :

- When encoding an CDVC avi DV file in tmpGenc with "Output YUV data as Basic YCbCr not CCIR601" checked, or (exclusive) "Set equation for ColorSpace = CCIR-601" in the General environnemental settings, the luminance range of the resulting mpeg becomes correct (no fog).

- Procoder works like tmpGenc WITH the option "Output YUV data as Basic YCbCr not CCIR601" checked ...

I hope this helps.
O.

[yg1968]

See this related thread:

http://forum.doom9.org/showthread.ph...0&pagenumber=2

[FredThompson]

MainConcept codec 2.1.0 is VERY outdated. There have been at least 2 releases since then. I have 2.1.13.0 and 2.3.1. Please PM me to discuss how to perform your comparison steps with those codecs and also hosting your comparison. I have the old codec comparison site from @home but everything in it is too old. Regarding multi-generational degradation, just don't do it. DV is inherently lossy so no matter what you do you'll use quality somehow. Except in some extreme circumstances, there's no need to save a modified version, you can serve frames through AviSynth which are higher quality than DV can support. Also, you didn't mention if this was an NTSC or PAL comparison. I assume you were comparing PAL.

Update: I assume your sample clip is actually quite short, yes? It just occurred to me there is no realistic way I can duplicate your tests as I don't have your hardware. However, if you send me the test frame captured with MainConcept 2.1.0 I COULD work with that as long as we make the caveat very clear that the initial encode came from 2.1.0 only. I also don't know about any settings available in 2.1.0. There are quite a few in the 2.3.1 release.

Second Update: You didn't say which configuration settings you used for the CODECs. What was used?

[rozemab]

ulfschack,

Is the Sony DV codec available on the WEB? I recently purchased a Sony camcorder and do not recall the manual(s) mentioning a Sony written CODEC. I thought it was using the M$ DV codec installed under directx 9.0.

Brian

[taudule]

http://dshow.narod.ru/video/Sony_Sof...dec_v.2.23.exe

[ulfschack]

Hi and thanks for the replies.

@Taudule

(the codec is only used to encode transitions)

Actually anything that's been done to the avi after capture requires a recompression. I for one ususlly corrects the color in all my videos ... my camera seem to be confused about the colors purple and red

"fog effect" comes from the YUY2->RGB conversion

Confirmed! I saved as HuffYuv, thus no RBG conversion, and guess what (well you allready knew really ) the colors were the same as for MC. I find it a little bit strange though that the option "expand to 150%" didn't do diddly.

- Procoder works like tmpGenc WITH the option "Output YUV data as Basic YCbCr not CCIR601" checked ...

Yes, that's a pain in the behind. I can't get nice colors (get rid of the fog) when using Procoder without resorting to filters .

@FredThompson

Thanks for your support. I can't do anything before sunday though, as I'm going to my low-tech summer house for a couple of days.

there's no need to save a modified version, you can serve frames through AviSynth which are higher quality than DV can support

Yes, but you'll be surprised to see just how many that don't use frameserving. I've even seen moderators recommend intermediate saves. Once people get used to a solution the stick to it, or so it would seem

It is indeed PAL ... sorry for that omission.

@taudule (again)
The link you posted is where I took all codecs for the comparison. But I thought it a little strange that they were all "free", so I was unsure of the warez-factor. Do you suppose they're all free?

@rozemab

I thought it was using the M$ DV codec installed under directx 9.0.

It probably is, if you haven't installed any codecs yourself. Open a captured avi in VirtualDub and look under file->information to see what Codec's used. I think that Gspot is also program that can be used for cheking things like this, but I'm not sure as I've never used it myself.


Cheers


Cheers

[taudule]

I'm not sure, but i think the sony DV codec came bundled with "DVGate Motion" in Sony VAIO computers. And there are not many places where one can download it ...
So i don't know either the warez factor...
O.

[Mug Funky]

aight...

first of all, the "fog" is simply there because the DV stream is not being luminance corrected on decoding.

i actually prefer this to be, so i know it isn't clipping any colours that are actually in the original capture. i know most DV camcorders will record luminances outside the CCIR-601 range, so if the decoder corrects for this range, you will get your whites clipped off.

i prefer to adjust colours manually before recompression, so i have control over what is being kept.

hmm. i've done a few tests, and actually, Pinnacle was one of my preferred codecs because it decoded best - kept all the colour channels nice, without making them chunky (all the others did this, except Sony. Mainconcept 2.102 did it the worst).

i use Sony, because it balances speed with quality the best. it decodes pretty much exactly like pinnacle, but much faster, and it seems to have less generational loss (for most video editing jobs, there will only really be 1 or 2 recompressions.).

i think for frameserving, the decoder quality is paramount, because the output is only as good as the input. so out of the codecs you've tested, i use the fast ones (canopus and mainconcept) for capturing, because they don't choke up my PC and cause frames to drop. but for processing, i reinstall the Sony codec.

good that you're testing this stuff. there indeed does need to be more research done in this by people not actually trying to sell one of them.

might i suggest the "compare(clip1,clip2)" function in avisynth, which spits out PSNR data for the videos.

this means you can put an uncompressed or huffyuv clip as clip1, and have a DV codec in clip2. quite useful. i find they all tend to float around the 45dB mark when compared. the higher the better.

(one problem though is that pinnacle and maybe a couple of others will decompress with the whole thing shifted up 1 pixel, which can skew results badly. in this case, use generalconvolution to shift it back)

[taudule]

@Mug Funky :
OK i read your post here
http://forum.doom9.org/showthread.php?s=&threadid=57112
and i understand what you mean.

But then why :

-1-
The avs following script: avisource("canopus.avi") loaded in virtualdub => 0-255

-2-
"canopus.avi" loaded directly in virtualdub => 8-245 (about, that corresponds to the original if you're right)

(Levels mesured with the "levels" filter of virtualdub)

I wonder who does the levels correction when decoding, or who does not ?

Sorry to be a bit off subject, but i'd like to make things clear.


O.

[FredThompson]

1) AviSynth does the color conversion
2) Canopus converts to TV-safe RGB

Canopus is a...uh...not so good DV codec.

Registered MainConcept codec is v 2.3.1, 2.1.0 is a watermarked demo just to show functionality. If hacked 2.1.0 isn't working well, caveat emptor.

[Mug Funky]

@taudule: wow, i never noticed! i thought being anal retentive, i'd notice a thing like that.

hehe.

now i'm a little confused - i thought both avisource and virtualdub used VFW, meaning there shouldn't be a difference.

i guess Fred's got the plot there - avisynth doing the correction. maybe based on the fourCC code DVSD... if this is the case, if the code is changed to CDVC (the canopus native FourCC, also supported by mainconcept) it might come out differently?

hmm. i wish i knew more programming, and was far enough in the avisynth loop to know more about this stuff... maybe in another life i'll be a coder.

[FredThompson]

No, it's not a correction, it's a colorspace conversion. VirtualDub uses RGB only. DV is YUY2 colorspace. The Canopus codec decodes to TV-safe luminence levels. That is why black never looks quite black with the Cnaopus codec on a computer monitor.

Yes, if you change the fourcc code and have an appropriate decoder installed, you will see a difference.

[taudule]

I might make a mistake, but Virtualdub can work in YUY2 (see http://forum.doom9.org/showthread.ph...lor+conversion for example).
Only it's filters can't.
For example with it, you can save a DV stream in HufYuv...

And in that case (with CDVC), the HufYuv file is not in the 0-255 range... (it's identical on that matter to the original DV)...

Have alse a look there:
http://www.avisynth.org/index.php?page=Convert

If the video is already in the specified format, it will be passed through unchanged

O.

[FredThompson]

You are correct but that doesn't mean VirtualDub works in anything other than RGB. If you open a DV file with AviSynth or any other frameserver, the frameserver does the conversion. If you open a DV file with VirtualDub, the CODEC does the conversion.

This is easy seen by running two instances of VirtualDub. With one, open the Canopus DV file directly. With the other, open the Canopus DV file through AviSynth.

The file opened directly will not have the same luminance range. Blacks will not be quite black, so to speak.

VirtualDub, being on your computer, can display RGB luma from 0-255. However, the Canopus CODEC will feed VirtualDub the restricted TV-safe range.

[taudule]

Sorry to go on, but i think you're misleading.
Avisynth uses the codec to decompress.
Try changing the fourcc in the DV avi file to XXXX for example, then open in avs, you will get the message "couldn't locate a decompressor for fourcc XXXX".

OR, if you've a look in the avisynth sources, you'll see that
avisource() calls ICDecompressBegin() :
http://msdn.microsoft.com/library/de...macro_33n2.asp

O.

[FredThompson]

Ah, yes, I see what you mean. AviSynth certainly calls the codec but it's not asking for RGB. Correct me if I'm wrong, doesn't VirtualDub request RGB? How else can the difference in appearance on opening be explained? If you look at the decompression options for MainConcept, you'll see it can return different colorspace and 16-235 is a non-default option. It sure looks like Canopus is returning full YUY or 16-235 RGB depending on how the colorspace requested. IOW, If AvySynth is opening DV, AviSynth does the conversion to RGB. If VirtualDub is opening DV, the DV codcec does the conversion to RGB.

[bb]

Maybe you should experiment with the "pixel_type" parameter in AviSource, which controls the output of the decompressor. There may be a difference whether you choose "pixel_type=RGB24", "pixel_type=RGB32" or "pixel_type=YUY2".

Just an idea.

bb

[taudule]

@FredThompson
For Virtualdub, sh0dan's answered in the frame i previously quoted.
It requests RGB24 for display, not for processing.

So if we sum up (for canopus DV codec):
-1- DV file ->[CODEC gives YUY2]-> avisynth_YUY2 ->[? converts to RGB24]-> virtualdub display -> luma range 0-255
-2- DV file ->[CODEC converts to RGB24]-> virtualdub display -> luma range 16-240 (or so)
Edited on 07/30
replaced :
-3- DV file ->[CODEC gives YUY2]-> virtualdub encode ->[HUFYuv keeps YUY2]-> luma range 16-240 (or so)
by :
-3- DV file ->[CODEC converts to RGB32]-> virtualdub encode ->[HUFYuv keeps RGB or converts to YUY2]-> luma range 16-240 (or so)

And yes i think you're right, the question mark should be replaced by avisynth. When i get time, i'll check the source code (no avisynth developper listening ?). That should tell if yes or no it is avisynth that converts to RGB and if yes or no there is a level correction a this point.

@bb
thx for input. I'll have a look.
O.

[FredThompson]

I think you are correct. There is also a 4th scenario:

-4- DV file ->[CODEC gives YUY2]-> virtualdub fast recompress ->[HUFYuv keeps YUY2]-> luma range 0-255

The 0-255 if really an RGB range. We both understand it to mean the entire luma range.

This scenario would be helpful if you were just doing cut and paste editing. -3- is full recompress operations.

I just checked the AviSynth site because I thought RGB32 was the default. I guess it depends on what VirtualDub requests, but that's just a guess.