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

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.

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

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.