DV-Output with Blocky Chroma

[krieger2005]

I have a Problem with a captured Film. It looks ok, but when i separate Y-U-V-Planes the chroma Planes are very blocky. The Y-Channel look ok. I must say, i use "ColorYUV(autogain=true)" to visualize the Blockiness... but still: The Block-Artifacts are there.

My Codec: Cedocida 0.1.6.
Settings:
- Encoder: Quality=high, force=off, YV12, Tried DV subsampling and MPEG2 interlaced.
- Decoder: force=on, YV12, MPEG2 interlaced
Source: PAL

Is this Blockiness "normal", or can a Capture-Codec-Swap help?

[henryho_hk]

How "blocky" is it? Please use "VirtualDub 1.6" to produce a snapshot or write an AVS script to produce outputs like http://forum.doom9.org/showthread.php?p=733216#post733216

[krieger2005]

Okey... i thought, if this is normal, than someone would it say. But if a script and Screenshots needed, it seems to be not "normal".

I used this script to generate two screenshots:
avisource("E:\scene'0.00.36.18.avi")
y=mt_Lut(uexpr="128",vexpr="128",y=1, u=3,v=3).ColorYUV(autogain=true)
u=UtoY().ColorYUV(autogain=true)
v=VtoY().ColorYUV(autogain=true)

StackHorizontal(y,StackVertical(u,v))

# Decomment, for Interlaced output
#return last

# DeInterlaced output
TDeInt(mode=0)

Here two Screenshots. One on a Interlaced frame, one on a Deinterlaced one:
http://img204.imageshack.us/img204/138/frame21se3.th.png (http://img204.imageshack.us/my.php?image=frame21se3.png)
http://img204.imageshack.us/img204/4461/frame25deinterlacedtm2.th.png (http://img204.imageshack.us/my.php?image=frame25deinterlacedtm2.png)

So the Screenshot show
left Y-Channel
Right-Top, U-Channel
Right-Bottom, V-Channel

[henryho_hk]

This seems to be a panning scene (maybe some vertical shaking as well). I don't have high-motion scenes for comparsion. Can you make a snapshot of a relatively static scene?

[krieger2005]

Okey. This frame is relativly static: http://img76.imageshack.us/img76/2466/frame41intif3.th.png (http://img76.imageshack.us/my.php?image=frame41intif3.png)

The Problem is the same when you look at the building at the left. I will try some another codecs... Maybe i make something wrong.

[krieger2005]

Okey. Here are results of MainConcept (no change in the settings):
http://img206.imageshack.us/img206/5395/mainconceptmotionmk2.th.png (http://img206.imageshack.us/my.php?image=mainconceptmotionmk2.png)

I have converted the Picture above to YV12 by Avisynth. Here a YUY2-Output:
http://img177.imageshack.us/img177/8994/mainconceptmotionyuy2lo4.th.png (http://img177.imageshack.us/my.php?image=mainconceptmotionyuy2lo4.png)

Interesting: There seem to be some periodic artefacts in the Chroma-Channels.

[krieger2005]

Okey. I tried now to capture in YUY2 and output the results in YUY2. The Results look better for me. Still the Block-Artifacts are there.

Maybe i should not conclude on the Quality when using "autogain=true"...

[henryho_hk]

I have a nearly static scene (a man walking in a room w/ the DV camera put on a stand). The areas with low chroma values are also very blocky. And in overall the blocks are indeed amplified by "autogain=true".

Also, I notice that there are some interesting dot patterns in the chroma channels of your snapshots.

[krieger2005]

The dot-pattern is only on the Mainconcept-Codec. I think this is the result of the Chroma-Handling while capturing of the Codec.

But now i know, that i probably made all right. Thanks you.

[JohnnyMalaria]

The dot-pattern is only on the Mainconcept-Codec. I think this is the result of the Chroma-Handling while capturing of the Codec.

But now i know, that i probably made all right. Thanks you.

Actually, the dots are because of a bug in the Intel Performance Primitives library that Main Concept use.

We use the same library for our DV decoder and had the same problem. We ended up writing our own routines to replace the buggy Intel ones!

[FredThompson]

That's partially helpful. You should say who "we" is...

[JohnnyMalaria]

That's partially helpful. You should say who "we" is...

Yes - it would help! Thought I had set up my signature. It should show up now...if not: http://www.enosoft.net

[FredThompson]

Oh, ho! I was at your site a few days ago. Wasn't there a recent release of the freeware firewire device name tool?

Let me see if I understand correctly, the enosoft decoder has its own math primitives which (you say and I don't doubt but haven't verified yet) create improper decoding when the MainConcept codec is used, correct?

I've looking over the site again and the white balance part would be a godsend. I shoot a lot of stuff under industrial lighting, none of which is full spectrum. Too often, mixed light sources cause all kinds of balance issues. So does the stupid auto-white which is constantly readjusting :(

What about 4:2:0 chroma errors such as described at http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html and the reason reinterpolate420 came to life?

[FredThompson]

Actually, one more question: Why is this just a decoder and not a full codec?

[JohnnyMalaria]

Oh, ho! I was at your site a few days ago. Wasn't there a recent release of the freeware firewire device name tool?

Yes - "FriendlyDV". We wrote it because Vista (at the moment) doesn't create 'friendly names' for DV devices when you connect them. It seemed an obvious extension to allow the device names in XP to be changed, too.


Let me see if I understand correctly, the enosoft decoder has its own math primitives which (you say and I don't doubt but haven't verified yet) create improper decoding when the MainConcept codec is used, correct?

Intel provide a primitives library ("Intel Performance Primitives") for doing a lot of the grudge work of video encoding/decoding. One of the functions in the library contains a bug that, under certain circumstances, leads to the artifacts noted before (usually a dark pixel in the top-left corner of every 8x8 block). Intel acknowledge this and have stated it will be fixed in a future release. For this specific routine, we have modified it to remove the bug for our DV decoder. I believe early versions of the MainConcept decoder suffered from the Intel bug and that MainConcept have since corrected it (I haven't confirmed it).

Looking over the site again and the white balance part would be a godsend. I shoot a lot of stuff under industrial lighting, none of which is full spectrum. Too often, mixed light sources cause all kinds of balance issues. So does the stupid auto-white which is constantly readjusting :(


Thanks - if you have any suggestions for improvements, please do let us know.

What about 4:2:0 chroma errors such as described at http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-special-report-chroma-bug-4-2001.html and the reason reinterpolate420 came to life?

DV is different - there is no differentiation between how progressive and interlaced chroma are processed. The problem in the referenced article is MPEG-specific.

[JohnnyMalaria]

Actually, one more question: Why is this just a decoder and not a full codec?

The need at the time was for a way to display the timecode etc from existing DV material (either live or AVI file). We have written our own encoder and it is used within the Enosoft DV Processor.