@Disdausdebil - really wonderful. Any chance of a workflow description?

@jefelemur One of the better films i've seen in a long time. Loved it.

@LPowell what's the use of peaceful coexistence of 24p and 50i modes? My assumption would be that anyone shooting a project in 24p (and hopefully soon 25p) would not need a good 50i mode in the same patch and vice versa. Or is it for the folks who use de-interlaced 50i for slow motion? I would personally prefer 30p and 50p or 60p at 720 resolution and could perfectly live without a good 50i mode, or without an interlaced mode all together. To me the most useful modes in a patch would be one that allows for the best quality for handheld or moving scenes, regardless of the data rate, a second mode for static shots with best quality and one mode for rather long takes (interviews, debates, speeches etc.).That kind of recording doesn't have to be top quality. For anything else I don't see the point in saving card space. After transcoding to prores hq, dnxhd or cineform one ends up with high data rates anyhow. So maybe a one-patch-serves-all is not so useful taking hard disk prices into account?

@Disdausdebil Wonderful colouring and superb editing. Love it. @jefelemur Funny! I'm like that when I want a shave! Good luck in the festival comp.

I'm beginning to wonder what advantage do B-Frames really bring...

Let's face it, in their nature they make sense and can bring serious savings when there is motion in the footage that is non linear with time.

Consider this timeline:

1 23 4 56 7

I BB P BB P

Sure, a B-Frame at point #6 will most of the times look more similar to that P frame at point #7 than to the P-Frame at #4, but not by much, and you need to use at least a 2(+) B-Frame structure for that to occur.

In reality how often does that happen?

In reality how often do you have complex occlusions that occur within a 3 frame span?

Now, adding insult to injury, let me show you what happened a few days ago when I was investigating a 2fps timelapse patch:

I - 160K

B - 8K

B - 8K

P - 3K

B - 8K

B - 8K

P - 3K

Surprised? I was! But it's normal, you see? Most of these frames are identical so the P/B frames are encoding null changes. Now why are the B-Frames so much bigger in this extreme case? Probably because their block addressing structure is a lot more complex, referring past and future frames something that doesn't need to be saved on a P-Frame.

Now, if B-Frames are so much complex and they explore very particular cases of footage, how come they are so "efficient"?

I suspect the answer lies in the quantization. B-Frames are small because they are heavily quantized and I mean a lot more heavily than P-Frames. I also suspect that given the same bitrate for the same footage, you could possibly get more OVERALL quality by using a 2 B-Frame structure but you wouldn't get more CONSTANT quality. I don't know, I haven't got the data, just a strong suspicion. :(

@LPowell might have a better formed opinion on this...

hey guys, here's a clip with Quantum 100 in action! Check it out! :)

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.

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

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

@LIN3ARX You're eyes are not alone!

Thank you. I'm expecting this patch impatiently

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.

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