Quality Test - SF Codec vs. MS Codec

Shredder wrote on 8/15/2002, 5:23 PM
Hi,

I created a pretty insane test image with lots of 1 pixel lines in various directions to see how interlacing affected the patterns.

Strangley I found out that depending on which codec you use, you get some pretty bad artifacting in the image.

When 'Ignore third party DV codecs' is checked, and 'Use Microsoft DV codec' is unchecked, that codec (which based on the help files seems to be SF's codec) handles the image better in some ways, but has a number of ugly artifacts in various parts of the image that look almost like dropped frame correction (which it's not, I did 3 renders & they all had the same issue).

with 'ignore' unchecked and 'ms' unchecked the artifact issues go away, but the codec has some problem with alternating 1 pixel lines of black and white, averaging them into grey. While this looks worse when zooming in, the codec did not destroy any of the shapes in the image, so those artifacts are visually less offensive.

with 'ignore' unchecked and 'ms' checked, I get the same results as the previous test, so I have to assume the previous test is using the ms codec.

Now I'm not sure that the SF codec is to blame, as I previously has the Adaptec DVSoft codec & even a main concept. They could still be lingering. I have no idea what codec's being used under the covers. How can you tell which one's being used.

I made a zip with my source image & 2 renders, as well as 400% zooms of key sections.

codectest.zip

I rendered these 3 progressive DV.

I'd appreciate it if someone could try rendering my source image with the SF codec & seeing if the have the same artifacts.

Thanks,

Jon

Comments

SonyDennis wrote on 8/15/2002, 6:03 PM

I haven't looked at your test images, but just be aware that super high-contrast edges violate video bandwidth specifications. Most video codecs are designed to deal with signals that fall within video bandwidth limits.

In other words, comparing how well video codecs deal with typical computer-screen images (like single-pixel wide non-antialiased lines) is like comparing trunk space between a Corvette and a Viper. Sure, they can haul stuff, but that's not what they are made for.

///d@
taliesin wrote on 8/15/2002, 7:55 PM
Coincidence?

It was yesterday when I made another very critical codec test to compare the Mainconcept DV-codec agaist the SonicFoundry DV-codec.
Rather critical means:
I made it up to the 10. render generation and I used pixel-shifting for EACH render process. It means before doing the first render I moved the whole picture 2 frames to the left side, rendered it, took the rendered file, moved the picture 2 frames to the right side and so on ...
This test method is part of the way the EBU (European Broadcasting Union) is testing DCT-depending codecs. It is said to be VERY critical because it really upsets the quantization step of the encoder and it is not to be valued with the regular way of working, editing, rendering. But it is a test to make very clear the differences in quality of various codecs.
So - whatever you do in you work on VV it is MOST unlikely you will have a loss like this, but the VV-codec loss is SO MUCH LESS compared to what happens to the picture rendered with the MC-codec. Believe me - the VV-codec really seems to be the best DV-codec available nowaday.
Now take a look at my render results (sorry, explanations on this web-page are german only, but it does not need that much explanation ;-))

--> http://dolax.bei.t-online.de/misc/codec_test/codec.html

Marco
Shredder wrote on 8/15/2002, 8:05 PM
Wow! I find it hard to believe that the MC codec degenerates so bad. The differece it clear!
Shredder wrote on 8/15/2002, 8:07 PM
Dennis,

Is there a way to tell which codec i'm using within VV? How can you be 100% sure youre using SF?

Also, it just dawned on me that these must have be DEcoding errors. I encoded them originally with the SF codec (i guess), and then did the screen shots back in VV with the SF codec & them the MS codec.

Thanks,

- Jon
taliesin wrote on 8/15/2002, 8:25 PM
> I find it hard to believe that the MC codec degenerates so bad.

Hehe, this is exactly what I thought when I saw the results for the first time.
I said: Oh sh..., I must have overseen another activated filter like 'levels' when having used the MC-codec. But - I haven't! - Some codecs are even worse than the MC one ...

But remember: This is a VERY SPECIAL TESTING ENVIRONMENT. The pixel shift method for render tests is not to be taken to value the render quality, it is for comparison tests only!!! You will NOT see losses like this in your daily editing work!!!

Marco
wolfn01 wrote on 8/15/2002, 11:53 PM
Hi Marco,

Thanks for sharing your test results!
Have you ever made a comparison with the Canopus codec, or what is your opinion about its quality?

Wolfgang
taliesin wrote on 8/16/2002, 4:38 AM
I would be very interested in this too! but I don't have the Canopus codec on my system - Is there a free codec version available?


Marco
wolfn01 wrote on 8/16/2002, 6:31 AM
Hi Marco,

I don't have it either. There is only a playback codec available at

ftp://www.canopus.com/pub/drivers/dvcodec.exe

Wolfgang
SonyEPM wrote on 8/16/2002, 9:57 AM
If the "ignore 3rd party codecs" pref is checked and "use Microsoft DV codec" is un-checked, you will be using the SFDV codec for both reading and writing.

Many people don't realize that the SDDV DEcoder is used in the above (default) config, and contibutes quite a bit to the end quality of a rendered DV-source project.

Also, with any DV compression tests, the first compression cycle is where you take the biggest hit. If you use DV source material (already compressed by the camera/deck), the first pass recompression (and subsequent recompressions) will be barely noticeable since you are already at 5:1 compression in 4:1:1/4:2:0 colorspace. If you use graphics or non-DV source material, you will probably see the artifacts of the 5:1 + colorspace squash, but with the SFDV codec it won't get noticeably worse in subsequent recompressions (unlike, say with the DirectX DV codecs which continue to fall apart).
SonyDennis wrote on 8/16/2002, 11:58 AM
Shredder:

> Is there a way to tell which codec i'm using within VV? How can you be 100% sure you're using SF?
I think SonicEPM answered this already ("ignore 3rd party" ON, "use MS" OFF), if not, ask again.

> Also, it just dawned on me that these must have be DEcoding errors. I encoded them originally with the SF codec (i guess), and then did the screen shots back in VV with the SF codec & them the MS codec.

Perhaps the reason the MC DV codec looks bad there is because it's only doing decoding, but not encoding (or vice versa). Multi-pass tests should be done with the same codec doing encoding / decoding mostly due to the RGB to 601 conversions being done (some codecs scale RGB 0..255 to 16..235 and then scale back later, which we feel is incorrect for a few reasons [think: *why* does 601 use 16..235]). So, if the MC DV codec scales on compress, but then we don't scale on decompress, you're not going to get the same image as if the MC codec was doing both operations.

///d@