@driftwood, When do you plan on releasing Quantum X ? I'm definitely excited to try Quantum for the first time, been using seaquake until now. Thanks for all your hard work.

@driftwood Thanks Nick! :-) Since this is the patch also with same having made together with you, I am glad if I get you to say so. Thanks again.

@Butt Thanks mate. ;-)

Any brief summary of visual differences in GOP3 vs GOP1? (other than the obvious technical differences)

@Balazer

Further testing on "Cake" patch & 1080i50: I'm sorry to report you that it doesn't span with ex-tele tuned on, although it spans perfectly with ex-tele turned off.

Riccardo

@Sage - Is correct I hope? Haha.

@rikyxxx, "Cake" is for 24p and Variable Movie Mode. I haven't touched the 1080i and 720p settings. Thanks for testing.

@Driftwood Nick, are there any unexpected problem in Quantum X development? Thanks.

Here's a music video shot mostly with v7. The panning wide shot in thew living room 9b. The ocean scenes are false color IR Pentax Kx.

Thank you. I'm expecting this patch impatiently

@LIN3ARX You're eyes are not alone!

i just installed again quantum 9v, and was thinking, are i am idiot?
i just switch to many times from patches, and to be honest they all look good.
But i want to check if my setting in the cake patch was off any diferences with quantum 9v
Just to much free time ad the moment, and still looking for the best patch for my needs.
keeping in mind, that it always is in daylight, with properly very nice weather.
80% off the time it will be very fast moving objects, so detail is not that big off importance. "yet"
But to learn to understand the gh2, working with all those different patches helps a lot.

i will keep it with quantum 9v for a wile now, because it works without problems, or perhaps i go back to sanity v3.1, what also give very nice results. lets see what the weekend brings.

ps, @balazer it works
i did also early this evening a test with iso 640 what give a very good and pleasant image to the eyes.. but a very high overall bitrate

@mozes, thanks for your report.

I was going to tell you that if you are happy with Quantum, there is no reason to switch. Cake is designed to give consistently high quality with more manageable file sizes, and spanning using the inexpensive SanDisk Extreme HD Video cards. It's not intended to be a replacement for the highest bit rate intra-frame settings.

Yes, the bit rate will be high when there is a lot of motion or noise. The bit rate is low when the motion and noise are low.

For anyone in the know, I am struggling to find a way to get the GH2 encoder rate limiter to work correctly for GOPs shorter than the defaults. The rate limiter seems to be assuming two GOPs per second, and when shorter GOPs are used and the quantization parameter is pushing the bit rate up against the limit, you get an oscillation between large frames and small frames with a period of about 11 frames. My solution was simply to not use a bit rate limit, and instead use a frame limit so as to keep the GOPs small enough to span. But that's not an ideal solution: it limits the sizes of I-frames in some cases, which prevents me from using a lower quantization parameter or longer GOP. Does anyone know how to get the rate limiter to work correctly with shorter-than-default GOPs? Flow Motion seems to have some setting that improves the situation. I'm now trying to deconstruct what lpowell has done there.

It's not the scaling tables. It's one of those other parameters: I just don't know which one yet. ;)

My approach in Cake differs from lpowell's approach in Flow Motion in a few ways. He's using the auto quantizer and adjusted the scaling tables to try to get the I- and B-frames to all have similar quality. I'm using a constant quantization parameter for I- and P-frames, and I've dumped the B frames altogether. He's using a constant bit rate of 50 Mbps for spanning, and 100 Mbps for no spanning. I'm using constant quality (constant QP, really) at up to 80 Mbps with spanning, using a frame limit to effectively limit the bit rate and allow spanning.

His approach has the advantage of not having a frame limit, which can give you amazing quality for high detail, low motion, low noise scenes, even at bit rates under 50 Mbps. That advantage goes away pretty quickly as you add a bit of noise or motion, or remove a bit of detail. My approach has the advantage of keeping the bit rate low when the video doesn't require a high bit rate, and automatically scaling the bit rate up as necessary to maintain constant quality. This arguably is more efficient than CBR, assuming that you can set the QP to what you want. I've chosen a QP of 22, which I feel gives great quality under all conditions, and makes the I- and P-frames virtually indistinguishable from each other while not bumping the I-frame sizes up against the frame limit too much. B-frames are more efficient than P-frames, but looking at samples of Flow Motion, his B-frames don't match the quality of the I-frames as closely as my P-frames do. I was happy to give up a small efficiency advantage to get the frame quality levels to match so closely.

B-frame quality has always been the problem with long-GOP settings: the B-frames were way too small and looked terrible. If you made the B-frames large enough to look good, then the P and I-frames were oversized, and then you had a high bit rate that completely wasted the advantage of the B-frames, and doesn't span.