Allowed value for "deblocking" are 0, 1 or 2. 0 mean "standard" 1 mean "reference only" (don't ask to me what is this...) 2 mean "disabled"

@willyfan thanks for the new information. did you find difference when using 1 or 2? the value 1 also works to avoid the GH2 problem or just the value 2 works?

Also, are there advantages in installing the Mainconcept GUI? Changing values in the GUI can avoid changing values in windows register? Is it a software for transcoding video or a codec pack?

@apeflos No advantage with mainconcept GUI. Avery software use his own filter, so you change in GUI only the filter installed in directshow but not the cineform one, nor CS6. The value 1, "reference only" I think that it apply deblock only on I frame. I don't know if it is a advantage, I think that is better "disable" @meierhans I tried to work on Adobe importer. Adobe use for h264 import a plugin named "ImporterMPEG.prm" located in polugin folder. May be that with a patch on this file it work... Don't try to change this file with the CS 5.5 one: don't work!! Unfortunately, the only alternative for the import plugin h264 in CS6 is always MainConcept, I tried it but it has the same problem and you can not disable the deblocking. @nomad I don't have a MAC for test, If someone want try, I suggest to start from System Preferences > Choose View > QuickTime > Advanced And check if there is the deblocking option.

@balazer I could. You want to see what it looks like?

@willyfan

This IS a deblocking decode filter problem, absolutely. And it is a problem from mainconcept. The best thing is disable deblocking in ALL mainconcept filter installed.

This hack would be worse than the digital rain disease it's intend to cure. The decoder's deblocking filter is a crucial component needed to smooth the horizontal and vertical edges between H.264 macroblocks. The encoder uses its deblocking filter to construct the internal reference frames that are used as the starting point to encode P and B-frames. If the decoder does not use its deblocking filter to reconstruct the reference frames in exactly the same way the encoder did, decoded P and B-frames will be contaminated with macroblock artifacts that cannot be cleanly filtered out in post.

@radikalfilm

...why do you have to be so smart and yet put out a "broken" patch? just saying.

Go ahead, blame the messenger all you want ;-P

Disabling deblocking saves CPU time. It trades accuracy for speed, when your CPU might otherwise be too slow to play back the video.

Deblocking is part of the h.264 spec. Compliant decoders all do deblocking the same way.

It seems I found a way to solve the diagonal rain pulsing pattern problem.

I am not sure yet.

I am doing tests.

If I find it I will upload the patch here:

http://www.personal-view.com/talks/discussion/11805/the-apefos-settings#Item_45

Problem is solved.

How I solved/fixed it:

I perceived that a grey surface is where the rain shows itself more, so I started correct exposure in a flat grey wall and start to underexpose a third fstop each time from f3.5 to f22 to get a dark image.

the main matrices, (scaling tables) was in a design to be a multiple of 6 or half six in all positions, or it was in a design to be 6 in the dct number and multile of 2 in the other positions. So I did a try to do the same in the deblocking tables, and then the diagonal rain pulsing pattern disappears.

First I set the deblocking intra and inter with 1 (one) in all positions. This means no quantization at all. Problem was solved but some macroblocks shows up.

Then I did a try in 6 in all positions, 6 was the dct number in all the scaling tables with other positions multiple of 6 or 3. It worked until the image got 3 fstops underexposed, then the rain appears, so I perceived that I should increase the deblocking values.

So I increased the deblocking intra all to 36 and keep the deblocking inter all 6, rain disappears. but some mud happens, it was so much deblocking.

Then I lowered it to 18 in all intraframe positions and to 3 in all the interframe positions. It worked ok, enough debloking and rain keep away. I did a try in 12 in all intra positions but not worked, 18 was ok.

so the deblocking intraframe is

018 018 018 018

018 018 018 018

018 018 018 018

018 018 018 018

(018 in the intra deblocking was ok to deblock the image, no need more, I saw the image frame by frame in 400% zoom, light, shadow and gradients)

and the deblocking interframe is

003 003 003 003

003 003 003 003

003 003 003 003

003 003 003 003

(006 in all positions also works for interframe, but I prefer lower quantization in the interframe, less mud)

I think the numbers in deblocking tables must be related to the dct number of the main scaling matrices. My scaling matrices has 6 in the dct number so using multiples of 6 or half 6 in the deblocking worked ok. I think if you use 4 in the dct number of the scaling matrices, then the debloking must be multiple of 4 or 2, just a supposition.

Also I perceived that the main scaling matrices works better when all the numbers have a relationship to be a multiple of some number, example: all multiple of 6, or all multiple of 3, or all multiple of 2. the camera processor does not stress with this design, see the matrices in the "the patch" topic.