We're working away at it. I've been looking at quantization scaling matrices, etc... There's still some more work to do. It will take a while longer. Hopefully, some good stuff comes out at the end...

I'm pretty familiar with the TI offerings. We've been looking at several codec's as background information. The Panasonic codec is pretty different, so it's a bit of a challange.

Chris

We made some progress with Chris discussing all this stuff.
Also it seeems like we found the bug causing strange bitrate behaviour sometimes.

Chris will make few things and test them so we'll understand it even better.

@Butt Make films! Driftwood Productions. I bought two GH2's (instead of going for an AF101) to B cam alongside my EX3s and 5DmkIIs, etc... With this hack, I'm just trying to understand the mechanics to get the best out of the equipment and I'm sorry if I don't understand the deeper in/outs of the engine. I just want to learn like everyone else! And help. Gonna donate some more dosh to Vitaly now. I can't believe the amount of work he has to process. And with the help of some incredible guys around him. Really pleased with what some of you experienced guys have achieved so far. Sometimes I feel he would be better telling us 'drones' what to do to help - I have no problem with that. You pros can then analyse the results. :-)

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?"

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

@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.

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.

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.

@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

@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.

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

@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.

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

Chris