Marco, technically what that is telling you is that the codec you are now using is recognizing those clips as potentially being compatible with itself. It's not really telling you what the clips are ... just telling you what they can be opened with. If you were to uninstall the MC codec and install some other DV codec, then they would probably be reported as that type instead.

Yeah, this is the direction I thought of too, but I was completely unsure about it.

Now I tested to import both a VV-encoded and an MC-encoded AVI within a hex-editor and it really looks like as if the header of both AVI are almost EXACTLY the same but all the compressed video is completely different.
I concluse it is the header which leads to strange results of displays. Well, maybe it is because both MC- and VV-DV use same header information but only the MC-codec is written into the Windows-System-Preferences. Now if an application tries to read the header of a VV-AVI it will be automatically lead to the Windows-System-Preferences entries and there only infos about Mainconcept will be shown and in the end displayed this way.
What you suggested would be another good method to proof it. I'll try to get the Panasonic codec and install that one instead of the MC-codec. I'm pretty sure it will happen exactly what you said about it.

In addition to that I made a render test with a critical test pattern which has a gradient grey-scale from RGB 0/0/0 up to 255/255/255.
The VV-render shows no difference at all. The Mainconcept render loses all information below 16/16/16 and above 235/235/235.

So I think this proofs it's completely nonsense to tell Mainconcept- and SonicFoundry-DV-codecs are same. Them are not even similar.

O.k. - I did replace the MainConcept-DV codec against the Panasonic-DV codec. And it's exactly what you said. Now every application displays VV-captured AVIs as Panasonic-DV. It can be some decompress-informations only.

Marco

Hi,

To clarify a few points:

1) Sonic Foundry's DV codec is indeed Sonic Foundry's.

2) Some codecs use the same header, which is why if a certain codec is installed it may appear to be another codec. However, that doesn't actually mean the indicated codec is actually being used.

3) The MainConcept DV codec is doing what it's supposed to color-wise. The YCbCr color space defines Y=16 as black and Y=235 as white, with the remainder of the spectrum used for synchronization impulses, etc. DV hardware playback clamps any values below 16 and above 235. I believe that Sonic Foundry has simply tuned their DV codec to the architecture of their own software, so the SF codec is also doing what it is supposed to do. It's not really an apples-to-apples situation.

MainConcept Tech Support

Thanks a lot for the infos about point one and especially point two.

To your third point:

Almost any dv consumer camera does produce over-white in the range over 235/235/235 if iris/shutter is not adjusted very carefully in highlighted situations in the white parts of the picture. This happens much more often than one would expect.

Now if you have one or two shots with such an over-white in it and you apply a dissolve on it and if you then do render only the dissolve and not the whole clip then there will be a luminance-jump in the over-white areas if you use a codec like MC. This is proven and fact.
The only way to avoid it is to render the whole clip instead of the dissolve only but this affects the gamma curve of the clip.

A codec like the SonicFoundry one does not care about it (as long as you don't tell'm to do). No jumps, no changes in the over-white areas, no affects to the gamma curve.
And whenever a video is meant to be distributed for computer or internet-use only this is a VERY advantage of such codecs. Canopus codec work the same way as SonicFoundry's does.

Marco

Taliesin,

Good information, thanks for posting. Expanding on your last post...if the footage is NOT targeted for computer use, but rather for NTSC television, are the SF and Canopus codecs at a disadvantage? Is clamping the IRE levels in software any more of a brute force method than that used by the MainConcept codec? Are either methods better than using a proamp to interpolate changes across the spectrum?

Luxo