Any more feedback on these, they seem to be pretty impressive, need 25p, 720p playback and 1080i25 pal

In addition, I often experience a message saying 'this motion image cannot be played' if I imediately try and play back a recording. switching the camera on and off sorts this it will then playback. often happens no matter which format I am recording in. BTW using PAL. Thanks

deleted: posted to wrong topic although I'm testing this one also!

I don't have experience with color grading, so I'm not sure how much it benefits from having higher quality recordings.

You can keep the constant-quality VBR approach of Cake, but get higher quality by lowering the 1080 quantizer setting to 20 or 18.

Driftwood's highest bit rate intra settings are the ones to use if you want the highest possible quality in each frame.

@balazer Thank you again for a great patch. Some of my films involve some amount of grading. Would you still recommend using Cake? @Mark_the_Harp I come from the world of audio (I'm a musician and record producer) and I remember the early days of Digital Audio (Protools 3 back in 1994) when we used to be meticulous about audio levels in order to preserve as many bits possible from the 16bits available to us then.

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.

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

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!!)

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

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.

@_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)

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

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