@Athiril

Thanks for your modded version of Cake (and thanks to Balazer too for Cake 1.2).

Only one question: does it span?

I've analyzed that last slow-pan shot (attached) in StreamParser to see what's happening. Turns out that Cake uses only ~60% the bitrate that Chris66 does for I-frames in that section, so no wonder Chris comes out on top.

So realistically Cake needs to up its overall bitrate to compete during motion - and possibly sacrifice spanning to do it (depending on your card). I think it's a worthwhile trade.

(BTW I get now that the motion quality comes from the constant-quality encoding, and the GOP size is actually irrelevant with that. Took a while to sink in : ).

@balazer, you can delete the PAL attachment (hover over it -> Delete). I think that's a new-ish feature here.

OK I tried to get constant Q with long GOP & B-frames working. I have limited knowledge of the advanced stuff, or how constant quality actually works (is it just the quantizer setting?), so it may be totally wrong:

Cake 1.2:

• 24p GOP = default 12 (unticked '1080i50 and 1080/p24 GOP size')

• B-frames = enabled (unticked 'Encoder setting 1 1080i/p')

• 1080/p24 Frame Limit = 12,000,000

• Quantizer for 1080 modes = 16

This game me (min/ave/max) 458,355 / 50,152,563 / 83,568,118 on a still/motion/heavy motion test clip.

I had to drop the Quantizer that low to get a decent average. Looks pretty good - but is it constant Q?

@Vitaliy_Kiselev, it would be great if PTool could show decimal values delimited, ie. 12,000,000 instead of 12000000. Much easier to read correctly.

Thanks @LPowell, that makes sense. My aim is to marry constant Q with long GOPs & Bs, so that we can (hopefully) get high-rate intra frame quality at much lower bitrates.

So I guess my modifications basically work. Problem is I know nothing about buffer tuning etc.

Another worry, including B-frames might damage Cake's intra-style motion, as I guess B's use even heavier motion interpolation than Ps?

@Mark_the_Harp : If your content wasn't varying in complexity periodically (lighting could provide a justification), looking at your graph I would bet the codec is constantly entering Fallback modes (lower frame sizes) and then exiting (bigger frame sizes) for short periods while the bitrate buffer is emptying or filling. That is not healthy and means bumps and lumps in IQ.

@_gl : 1080/p24 Frame Limit upper meaningful value is 10,000,000. I've seen posts by experts saying that above 10M there is no effect, so that's your target for the QP. Lowering the QP blindly will not get you better IQ since you could get a few blocks encoded at Q12 and then as the frame buffers empties, the last blocks would be encoded at Q20 or higher. I'll look for a great post to get you started and I'll put it here if I find it. (edit) Here: http://www.personal-view.com/talks/discussion/comment/37576#Comment_37576 Don't forget that the latest and most popular settings to PTTools 3.64d have made major tweaks to the Scaling Tables. This will result in bigger and better frames so the new QP=20 automatically translates to better IQ now.

@_gl The main difference between P and B-frames is that B-frames use both past and future reference frames, while P-frames only use past frames. A more subtle distinction is that B-frames compute a weighted average of past and future macroblocks to form each prediction. P-frames just use the best predictions it can find in past macroblocks.

However, in the GH2, the default Scaling Tables used for P and B-frames are coarser than those used in I-frames, and the B's are coarser than the P's. This is one of the reasons why B-frames are noticeably smaller than P-frames. This bit of engineering was based on the assumption that the encoder's macroblock predictions allow P and B-frame residuals to be encoded at lower quality with little or no perceptual loss. After examining the GH2's AVCHD encodings at some depth, I have doubts about how well this works in practice. That's why I customized the Scaling Tables in Flow Motion to match P and B-frame encoding quality to that of I-frames.

@_gl

Chris's 66M will have higher quality I-frames when it is not bit rate constrained, since it is using a lower quantization parameter. But Cake does not need to "up its overall bitrate to compete", because the goals of Cake are already met: good and consistent frame-to-frame quality, with spanning.

If you want higher quality, you can try lowering the quantizer setting to 20 or 18, but then you'll have larger files and you'll push up against the bit rate limit more often. You can raise the bit rate limit, but then you'll lose spanning at high bit rates. You can gain some efficiency by using a longer GOP, but then you'll lose spanning at high bit rates. And a longer GOP won't make a huge difference in efficiency, because the times when Cake generates high bit rates are when there is high motion or high noise, and during those times your P- or B-frames will be almost as large as your I-frames.

I find there is very little difference between the GH2's B-frames and P-frames. B-frames are more efficient in theory, but that relies on the encoder producing good bi-directional references, and it seems that the GH2 is not, for whatever reason. The B-frames and P-frames are just about the same size for the same quality. Feel free to experiment and see what you can find.

Mark,

Cake will generate constant quality up to ISO 3200 or so. It's not that quality will be bad beyond ISO 3200 - it's just that the encoder will be constrained by the bit rate limit, and it won't be constant quality anymore. You may or may not notice any decrease in quality, since the picture becomes very noisy, and it's hard to see any details among all that noise. If you're not much above ISO 3200, the bit rate limit won't make much difference. If your goal is to shoot ISO 12800 and apply the most advanced and intensive noise reduction post processing, you'll definitely be better off shooting at the highest bit rate you can.

As lpowell said, you don't need to be concerned about buffer levels so long as they are within the limits. (no buffer underruns or overruns)

No, you cannot tempt me, but you can make the changes yourself. Increase the GOP length and the top and bottom bit rates and lower the quantizer setting. But like I said, I don't think you'll see enough of an efficiency increase to make changing the GOP length worth it. Diminishing returns. Going from GOP3 to GOP6 will save something, and going to GOP 12 will save little more. You can calculate for yourself the efficiency gain of using a longer GOP: look at the difference in size between your I-frames and P-frames, and then multiply that by the number of I-frames that would change to P-frames if you used a longer GOP. If you want higher quality, you need a higher bit rate. Gop3zilla is an example of high quality inter-frame settings. Start with that and tune the quantizer setting to give the quality level that you want.

Hello friends, I'm very happy with Cake 1.2 and apparently many others who have looked at my test movie are impressed with the results. I'm not too familiar with interpretations of the technical numbers, but last night I used Mediainfo to peek into the numbers. To my disappointment, the data rates of my Cake 1.2 footage are 21 to 26 Mbs for the first video stream, while the maximum Overall Bit Rates are between 65 and 80 Mbs. @balazer, please explain these numbers. Should I seek higher data rates? Thanks again for great work. Izhar

Absolutely. If you haven't already noticed, you will also see the "time remaining" counter slowing down and speeding up as you shoot, in accordance with the bitrate and how much time the GH2 "thinks" it has left on the card.

@Vitaliy_kiselev I suppose no way of having a bitrate meter on the display (numbers or bargraph)?? IF the countdown timer speed is calculated from bitrate/storage available? Probably not but would be a fun thing to have (saves us looking at those annoyingly lovely pictures!!)

@izash I guess part of what's "high quality" is about whether it looks nice, and part of it is "does it take grading"? Maybe part of it is also, "does it let me shoot without suddenly crashing?"

I've been really surprised by what looks like a really detailed shot which turns out to have low bitrates, or a relatively static scene which has high bitrates. If you are panning the camera a lot on a lowish shutter speed, the bitrate won't necessarily be that high, because of the motion blur of the shutter speed. Slow camera moves (with a detailed object like in my video above) may call up higher bitrates. At high ISOs as @balazer mentions in his introduction to this topic, the patch might start to suffer as noise is introduced, probably because the camera has to encode the noise which is imposed on the image. However, as he also says, high noise will tend to mask the underlying picture quality anyway.

To understand more you could (and I haven't done this myself!!) do some shots one after the other (separate files) to test out different scenarios, for example:

• high iso (noise)
• low iso static or blurred shot
• low iso high movement (movement in scene)
• low iso high movement (camera movement)
• low iso very slow movement but high detail

...and any other scenarios you can think of, and just see what the bitrates do.

But personally I don't have patch envy with Cake. I'm really happy with it and have no plans to go over to Driftwood as for me, Cake spans even on my class 6 card, and I sometimes shoot long sequences. I also think Cake produces beautiful enough images to keep me happy!

Echoing what others have said, if the results are great even at low bit rates, you should not be disappointed! Efficiency is a good thing.

You might be concerned about the extra invisible quality of higher bit rate settings when you are color grading, or applying advanced noise reduction to footage shot above ISO 3200. But otherwise, what you see is what you get. If it looks good, it is good. Don't let any person or number tell you otherwise.