Quality is subjective. A proper constant quality encoder will have models of human perception of quality, and try multiple quantization parameters on each macroblock until it finds the one that yields the quality it is targeting.

The GH2 has nothing so complicated in its encoder, but you can get very close to constant quality by using a constant quantization parameter or auto quantizer setting, while having no frame limit or bit rate limit to constrain the frame sizes and raise the QP. In my testing, I've found that this approach yields nearly identical quality in I-frames and P-frames, with no need to change quantizer table assignments. With stock quantizer table assignments, B-frames are way too small and don't match the quality of the other frames, even when they have the same QP. My observation of the B-frames in Flow Motion is that they don't match the quality of the I-frames as closely as P-frames do even with stock quantizer table assignments. Perhaps there is additional work that can be done to get B-frames to match more closely, but personally I don't see a lot of value in trying to include B-frames, since P-frames are not that much less efficient.

Generally you don't want to have truly unconstrained bit rates and constant quality: we have hardware limitations, after all. In Cake, I keep the GOP size small enough to span by limiting the frame sizes to 3.33 megabits, which if all the frames are that size, is 80 Mbps in 24-fps mode. Without that limit, the bit rate for QP22 can go as high as 100 Mbps when you shoot at ISO 12800. Using a frame limit is not ideal, since you will in some cases be limiting the sizes of I-frames even when you are not at 80 Mbps, which will decrease their quality relative to the P-frames. For a frame limit of 3.33 megabits and QP of 22, the limit is really only apparent on the I-frames for high detail, low noise, low motion scenes (ISOs 250 and below on a tripod). Once you add a bit of motion or noise, the I-frames fall below 3.33 megabits. In high noise, the frame limit makes the I-frames have lower quality than the P-frames, but you'll hardly notice such a small difference among all that noise.

Ideally we could use the GH2 encoder's bit rate limiter to keep the GOP sizes small enough to span, instead of using frame limits. That would open up the possibility of constant quality encoder settings at longer GOPs, like 6 or 9. GOP6 would be an awesome sweet spot for quality and efficiency. I'm working now on how to get the bit rate limiter to work correctly at GOPs shorter than the defaults.

Shorter GOPs span at higher bit rates. GOP12 spans at 32 Mbps; GOP6 at 60 Mbps; GOP3 at 80 Mbps; GOP1 at 88 Mbps or perhaps higher. My theory is that the camera is writing a GOP at a time to the memory card, and that the write operation needs to complete in less than some length of time for spanning to succeed.

And of course we know that with the faster SanDisk Extreme Pro 95 MB/s 64 GB SDXC card, GOP1 spans at 146 Mbps. But I'm not keen on using that card, because, besides being very expensive, SDXC cards suffer from the occasional "file limit exceeded" error. If you need long recording times, imagine what happens when you encounter that error: to continue recording to the same card, you need to reformat it. That's a frightening scenario, avoidable by having multiple cards on hand (expensive), or by offloading the data before reformatting (slow). And yes, there is the technique of recording a short clip after spanning and before turning the camera off to avoid the error, but I don't trust myself to always adhere to that protocol to avoid a disaster.

@balazer when you say "cake beats it for everything else" you mean FlowMotion L50 and not 24H setting of FlowMotion, yes?

Thank you, @duartix. I want to quote what you said in the other thread about Cake:

Cake test 24p @ISO3200 & Panasonic 14-42mm. Very reactive bitrate. :) Amazing quality and detail. Great grainy shadows. No blocks. Absolutely no noticeable difference between I/P frames in my eyes.

I'm looking forward to having more people try these settings out and let me know how they're working.

I would think so, but we'll have to wait and see.

Just tested it. (Cake) Quality looks good. With Quantum 50, although also generally good, I sometimes got weird looking 'low resolution parts' in darker segments of an image. This looks more stable in the dark area's. I only tested it at ISO 160, since I like to minimize noise.

listen up motherfuckers. Youre never gonna be happy.

Amen

@balazer :

1 - About B-Frames and after some footage observations, I couldn't agree with you more, neither can the WIKI: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Controversies

2 - How's the progress on the bit rate limiter?

3 - The pitfall.

For someone that does his encodes in VBR for more than 10 years, this is now the approach that makes the most sense to me, however there is something that I wonder if it could be pursued to produce more satisfactory results: the L mode! In a perfect world we would have a bigger and different quantizer for 24L. But this is a Constant Quantizer ~ Constant Quality patch and there is only one quantizer parameter. Even though it works wonders on 24H because it's practically not limited, what is to be expected of 24L when all that is there to work with are bitrates and frame limits? It's a hard if not impossible task to make it Constant Quantizer/Quality. Could there be a solution in the quantizer/scaling tables? Or should we assume right away 24L will always be a fallback and shouldn't be used unless we're prepared to give up true VBR?

And isn't it strange that the GH2 works originally in 24H & 24L modes with the same quantizer?

I've been trying to follow these conversations about P-frames, b-frames, GOP, etc, and I have to admit it's over my head. I'm still not sure which patch I need. The real issue I find with the GH2, more than anything else, is noise. I just want decent bitrate, good motion, and extremely low noise (or as low as possible) in low light/low detail areas. Is cake what I'm looking for, or would I be better off with an older patch with a higher AQ level? I only need the camera to be stable in 1080 24p. Someone please help. My head is spinning over here.

I appreciate the response balazer. I know to keep my iso levels down. The problem I have is often my subject is lit but the background isn't. In that case the background is always noisy. Never heard of Neat Video, I'll have to check it out. What about Driftwood's Quantum v7? I saw some pretty impressive footage shot with that patch. Having trouble finding it though.

And definitely check out Neatvideo, it can work wonders!

@izash : As far as I can recall, @balazer hasn't targeted the 720p modes in Cake 1.1. In principle you could merge them safely with FlowMotion. That's what I did for my TimeBuster patch.

(bit late but) @yrowan, no patch will remove noise for you. In fact the high quality patches will preserve as much noise grain as possible, as the camera counts it as detail. That's actually a good thing, because the raw noise can be removed better later (with something like NeatVideo) than the splotches you get from noise-reduction or heavy compression.