@Stray
@proaudio4

Good morning! Since I live in the other side of the earth. :-)
Since many comments were got, please point out, if there is a point from which it has escaped in my comment.

@Stray, I appreciate that you did the wonderful test first of all.
I will be glad if you take to 3GOP taking advantage of this.
In order to keep the bit rate from falling at the time of lowlight, I have adopted AQ3, as you understand.

About Iframe size, probably, I enlarged to a slight degree, if you did not make a new crazy test chart.
In fact, in the test of Pappas, even if large to a slight degree, it had cleared.
If you can do it larger, I want you to change by all means.
Although I am also trying hard, I cannot clear extream stress test easily. :-(

After opening a patch to 1 page of this thread, of course, I continued testing AQ2.
Although frame size was able to be enlarged a little, I give priority to frame size not falling at the time of lowlight, and am making it AQ3.
Should it be used properly by personal liking about these AQs?

@proaudio4, I appreciate to having evaluated my patch and testing after this.

I also made 88M3GOP,AQ3 of the practical level.
Although Pappas test was also cleared, since a new Stray's chart test is unclearable, 66M is used reluctantly.
I also hope to realize 88M3GOP,AQ3.

As follow to the information from Chris, I have looked for the sweet spot, after understanding it in advance.
However, if I say honestly, I think that this patch will not pass your extream stress test, although an error cannot come out in practical setup.
In fact, my friend is using this patch at work satisfactorily, and I have not felt dissatisfaction, either.
Since I do not know to give how much stress tolerance to these settings well, in order to understand this standard, I am looking forward to the result of your test.

And I am looking forward to the direction as a result of a lowlight test rather than the stress test.
Because therefore I chose AQ3... :-)

P.S:Please point out, if there is a strange place of my English.

@driftwood you are great, you're the savior of the GH2, hahaha:)
accept all respect from me.

@bkmcwd,

Thanks.
I will test your settings tomorrow. Yes, I agree on your choice for AQ3.

Wow... WTF, looks cool though! LOL

@bkmcwd The patch is breaking the maximum bitrate on any shot with a reasonable amount of detail, so it is pretty unusable as something very odd is then happening to the framerate. Take a high detail shot, record what the shot length was, then look at the frame count. The frame count is off (wrong) from what it should be, and by a lot too in some cases. Now I do have some shots that are fine, shots with low detail that didn't break the bitrate limit. So maybe shooting in lowlight and with low detail you may get away with it, but it's way too unpredictable.

What is very interesting about this patch is it does not exhibit the cadence problem when it breaks the bitrate limit, but sort of skips frames, changes its frame rate, it does something odd anyroad. This has led me to an epiphany about just what the hell we're doing here. Well, that and the last several hours of tweaking settings too.

We set a bitrate, then behind the scenes a number of other parameters are being set, and we do have some of these parameters available to us in the testers section so we can override them. But I don't know if we have access to all of the parameters, or functional adaptations resulting from a bitrate change. For me, to use a data analysis saying, 'All the numbers aren't on the table' ;). As in we don't know enough, but I think we do probably know enough to say now that the balancing act required to get a GOP3 at a bitrate below 132Mbps is probably never going to happen. That could be a limitation of this ptool version, or it could be something we can never overcome. Dunno.

This is not a simple matter of change a parameter, and then see a direct correlation to the change within the result ('all the numbers...' etc). It could be that some of the relationships are non-linear, they are definitely adaptive. Soo.. think about what we know, setting the frame limit most definitely puts a clamp on the frame sizes. Setting AQ affects the quantizer values it uses (the range of them) this affects (to put it horribly simply) how much compression is done, thereby affecting the encoded frame size. How does the frame limit affect its compression strategy in relation to the AQ you've set ? Does it know that its going to have to switch to a lower QP from its range to fit a frame within the limit, and does it do so effectively and elegantly ? As in, does it choose a 'best' QP from the basis of the frame limit against what is in the available range of QPs given by the AQ setting ? Is that even possible ? I don't have the answers to any of that. Now add to that the fact that while we're tweaking FB1 + FB2 we are either shrinking or extending its range of QPs, its available compression strategies. Then we have the top/bottom settings which IIRC (although I may have missed a change in the theory) also effect the possible max frame size in someway (though I don't think we have a good explanation of their function to go on on here yet). What your patch has shown is that it is possible just by changing these parameters to create a stream that breaks the maximum bitrate we've set. This is serious shit if you think about it. Changing parameters such as lowering the frame limit does not solve the problem, as there are other things, adaptive changes that happen which cause other problems (cadence) and in the case of your patch don't actually lower the frame size. Soo.. thats likely down to the larger top/bottom settings you've set. Turning them off incidentally just causes cadence problems instead, but the frame rate is right at least. Also, upping the maximum bitrate to cope with the larger bitrates the patch is generating doesn't solve the problem either, as other adaptive changes get made that throw something else out of whack.

I'm not saying that its impossible to build a GOP3 at lower bitrates, just that it is going to involve a hellish amount of very, very small tweaking. Maybe it all goes back to what @vitaliy said many weeks ago, that this codec is built for GOP12 and more changes need to be made for it to be possible to effectively lower the GOP. It is logical that a lower GOP means a higher bitrate as you'll have more I-Frames, it needs more headspace. Driftwood has created low GOPs that seem to be quite stable. To do this he has clamped the frame size quite a bit. This is because I-frames are the largest frames, and a stream of just I-frames is going to eat your bitrate, therefore the I-Frames are going to have to be smaller than they would be in a longer GOP setting. Also because of the headspace he's had to give it in terms of the max bitrate, you can under certain conditions make it break when it actually tries to hit that max bitrate. If it was possible to create a GOP3 at 66M or 88M I feel the frame size would have to be so low, and/or the QPs so limited and high, as to make it not worth it in terms of image quality. So, I'm personally jumping off the low GOP train for a while. Heh, got to let the full horror of my realisation, and the tests I've done in these small hours sink in properly. @vitaliy @cbrandin If I'm completely wrong in any of this please correct me.

@proaudio4
@MbhuyKo
Thanks!
Since I am improving now, if I can do it, of course, I will share.

@chenopup Im getting 4 1/2 mins on my 8gb Extreme

Stray..
Wow, thanks for your post.

I hear you regarding bitrates under 88Mb/s with shorter GOP leading to smaller i-frames. Hmm....
So in that range (88M), maybe GOP6 could be maximized.

But, it sounds like you're off low GOP.

Have you been able to stabilize 88M AQ3 GOP12? Either standard or max variation for buffer settings?

I have not tried your 88M AQ2 GOP12 (MAX VAR) with your new extreme dense chart. I bet is passes.
If we could get an AQ3 version, this would make a great comparision. I know bkmcwd has been working on the GOP3 AQ3, but as you know is having issues with the average exceeding the max bitrate.

@proaudio4
@MbhuyKo
I stick what was converted simply once.
However, I do not know whether this is worthy.
Since it is Q=18, naturally at the time of lowlight, frame size becomes small.
So, I like 3GOP AQ3 stuck previously.

@Stray
Thanks for your advice.
Since I am also the same idea as you fundamentally, I am not going to advance this setting full of P frames any more.

Although I was still adjusted 3GOP AQ3 this way and that, if preparing it as a theory, I cannot make it surely stabilized...
Although there is a place where my 3GOP AQ3 is strange, the recording itself is very stable and there is no problem.
What should do what with where ...

@bkmcwd I'm not sure at the moment, Thinking more about it, it isn't breaking the bitrate by much, so it could be okay. Even Chris's stable patches can go up to 1 or 2M over the max and seem to be fine.

@Stray
I also tried instantly.
If many hours are spent in my "outlaw" approach, although it may be stabilized... I'm not sure.
When I can take time, I also tamper with many things based on this for study.
If a model answer comes out, please let me know!