@cbrandin

Thanks for ideas, Chris.
Did you try 1080i and 1080p at high bitrates and look at quantization values?
I don't know how they could be the same as I frame size also increases.

The problem is that StreamParser hasn't got any video stream analysis parts in it (it's all transport stream based) - and writing all that is a very big deal. StreamEye does have that capability, and for $50. I wrote StreamParser to do what other programs couldn't, I really don't want to replicate Elecard's efforts, especially since they have dropped the price to $50. We are talking hundreds of hours of work here - I'd rather do other things.

Chris

I have been testing lowering the minimum quantization value. This is not incorporated into PTool yet; Vitaliy made a special patch for me to test.

I tested three scenarios (all in the 24H mode): Panasonic factory settings, Vitaliy's suggested 42000000 setting for 24H, and finally Vitaliy's 42000000 setting plus the minimum quantization value lowered from the default value of 20 down to 10. The test chart was an image containing gray, red, green, blue, cyan, magenta, and yellow. Each stripe was a gradient going from full saturation to white.

Chart:


Vector Scope of factory 24H settings:


Vector Scope of PTool suggested 42000000 for 24H settings:


Vector Scope of PTool suggested 42000000 plus quantization minimum set to 10 for 24H settings:


It appears that a lower quantization value does improve color fidelity (which means less blocking). Notice that the yellow axis shows a significant color artifact in all but the quantization=10 captures.

These are just the static tests, I plan to do some dynamic testing later.

[UPdate] The quantization minimums don't seem to be changing as much as I expected. Maybe they won't with static scenes. So, at this point I'm still analyzing exactly why the color fidelity is improved with this patch.

Chris

Yup, that's exactly what I'm experimenting with.

Chris

@cbrandin - Interesting observation about the eyes' ability to resolve yellow. However, if the encoder is detecting yellow solely on the basis of hue, I'd anticipate a problem with dark shades of yellow, i.e. yellowish-brown. The eye can discriminate dark shades with much more clarity than it has for bright yellow.

Actually, that doesn't really make sense either. It's the test with the lower Q value that is the best. The problem is that it was only used in the top part of the very first frame. I'll have to repeat this test. Who knows, maybe my cat walked in while I was running the last test and changed the light reflected on the target slightly.

Chris

@driftwood
First, do not change GOP or anything else other than one parameter.
Second, fix ISO.
Always attach your settings or list them complete, as I can't understand anything from your tests.

@driftwood
I can't understand that you are doing. Absolutely.
You changed GOP, and vary ISO, bunch of other settings.
It is useless results.

Most probably it is better for you to use http://www.personal-view.com/talks/discussion/335/pro-gh2-avchd-encoder-settings

I don't know if it would help but there is are a number of charts from http://www.dsclabs.com/ that might be useful for this kind of testing if anyone has access to one.

A short thought:
The "Encoder Settings" look to me like scaling factors for quantisation tables.
720p and 1080i/p seem to be addressed each with 4 progression stages
to control kind of a 4-step adaptive matrix.

The easier-to encode progressive format start with lower factors for temporally smooth content: 720p (2) 1080i/p (3). The lowest 1080 stage (3) can be shared by both i and p.
(A temporally smooth picture does not differ much in 1080i or p.)
The more temporal ripply content becomes, the more quantisation factor has to rise,
harder for i than for p.
Seeing the (17) for 1080i it becomes obvious that 1080i is harder to encode than 1080p, and would need more bits. So in consequence this has to compensated by even higher quantisation factors to have the same bitrate results.
The last factor for 1080i is 17. Why 17?
I am looking for known H.264 restrictions and correlation in integers first
and find:(17)*3=51.
Now multiplied by 3 we see 51, this would resemble the highest quantisation factor implemented in this encoder. And (2)*3 would mean the lowest quantisation factor of 6, maybe a comfortable value for temporal smooth 720p content.

Furthermore it can be explained now why the encoder working at 720p and with lowest quantisation factors together with comfortably higher given bitrates sees no need to insert B-frames.
The encoder simply does not need to save any bits here and produces P-Frames only (beside the occasionally I-frame at GOP boundaries).
This can be useful to have higher quality and easier encoding/decoding.

On the other side forcing a 1080i encode to have only a last factor of 4 instead of 17 violates either bitrate restriction or forces too many bits.
So that encoder freezes, or SD card can not keep up. This is not useful at all.

I would leave these controls alone at first, rather concentrate on the buffer controls.

While implementing x264 it became obvious how important proper buffer implementation and following HRD model was, for getting broader playback compliance.

@driftwood
You do not understand that you are doing. :-)
I know that you want to help very much, so, I'll try to explain your error.
Right now all your settings are identical, absolutely.
You need to check 1080p24 setting high and change it to each option (except original) sequentally and test. Check that you record in 1080p24 24H mode on camera.
Camera must be fixed on tripod aimed at well lit and static scene.

@driftwood
Nope.
1080p24 Settings High > 1080p24 Settings Low etc.
You can't go wrong, as all you need is select item from dropdown list.

Thanks for removing the comments! Old chinese proverb say "do not despise the snake for having no horns, for who is to say it will not become a dragon?"