Personal View site logo
GH2 Cake v2.3: reliability and spanning in 720p, HBR, 24p, and VMM at 2-2.5x stock bit rates
  • 609 Replies sorted by
  • Cake 1.2 on 25p/HBR averages 50mbps vs 80mbps in 24p of the same scene one right after another.

    I've modded some settings to reflect all the 24p settings, got 80mbps vs 79mbps basically outdoors in detailed complex scene. Another test more compressable indoors was 49mbps (24H) vs 45mbps (25p HBR).

    I think this should help satisfy HBR 25p users to get similar rates with 24H rather than much lower, of course I haven't been able to test 30p HBR, you may want to try increasing bitrate to get similar sized frames.

    I wanted to post this last night by my comp crashed so I went to bed.

    edit: still seems to be some differences in bitrates in some scenes.

    GH2 Cake v1.2 HBR mod - seta.zip
    1K
  • @Athiril

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

    Only one question: does it span?

  • @rikyxxx I haven't tested in depth yet, I'm still modding settings to try and make it perform at a 25/23.976 greater bitrate vs 24H instead of a little lower.

    The above mod is just copying settings from 24H into the settings that affect HBR.

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

    grass.png
    1920 x 1080 - 3M
    Cake1.2.gif
    488 x 676 - 49K
    Chris66.gif
    488 x 676 - 50K
  • 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.

    @balazer, if we sacrifice spanning, then why not use a long GOP with B-frames for maximum efficiency? Would that work with constant-quality?

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

  • @_gl The AVCHD encoder works at a constant QP by default, which is 20. This can be set manually, as you did above, with Quantizer for 1080 modes = 16. Typically, you'll see QP vary over a +/-2 range in I-frames, but the encoder will normally use the default QP in P and B-frames.

    If you want to use Adaptive Quantization instead, you can use PTool's AQ patches, as Chris did in his 44Mbps and 66Mbps settings. However, the AQ patches are designed for use with long-GOP formats. For short-GOP, Chris recommends setting QP manually.

  • 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?

  • @LPowell Not to hijack this, I hope, but could you explain what the buffer analyzer is showing me in my post of feb 21st, and whether that looks "healthy" to you? What patch settings affect it (if that isn't a complex answer)?

    Normally the graph is around the middle or above of the range, this one was a bit unusual being so low. However, I don't know if low=bad and high=good or something else entirely. Could you enlighten me?!

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

  • @duartix or @LPowell That makes some sense. I was shooting at quite a high iso and the sections where the bitrate goes high in the stream seem to correspond to the parts with the buffer line going down (the stream and buffer analysis are from the same clip). Where the buffer line goes down are actually the bits with least movement (but some movement, very slow) and I was shooting at 1/25sec so maybe the frames with more movement were just more blurry and hence using less data? I no longer have the footage but I can test again with something suitably deathy and noisy. I think @balazer said that Cake might not be so good at high isos, and maybe that's why, but I do love the look I'm getting from it.

    But if this is a buffer issue, what would I do to stop that happening? Set the QP back to 22? Or some other thing? Is this buffer thing to do with the card or with the settings on the camera? Sorry for all the questions, but I'd love to understand more about how that buffer behaviour relates to the patch...I'm not even sure what the red line (61 441 024) relates to.

  • @_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 Your buffer trace screenshot doesn't necessarily indicate that anything went wrong. But if you can correlate the buffer trace with Stream Parser recording glitches, it may provide some clues. Aside from that, as long as the trace doesn't climb above the horizontal limit line (at 61.4M in this case), the patch is working safely within the buffer's upper limit. That limit is set by the "Bottom Setting" for each mode.

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

  • Thanks for all the input guys, I'll look at this again tomorrow.

    @duartix, I did try intermediate quantizer values, but with the long GOP & Bs they produced very low average rates, IIRC 18 only produced around 35mbps average. 12 and 14 both topped out at ~65mbps, so I was clearly hitting a ceiling there. But 16 dropped that to 50mpbs.

    I get that to do this properly, you really need to analyze the streams in detail. With that in mind, @balazer can I tempt you into creating an efficient higher-quality version of Cake, that will compete with Chris66 during motion? I'm happy to sacrifice spanning because IQ is more important to me.

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

  • Hi all, thanks very much for the pointers about what stream analyser is showing and what it means.

    BTW here's a quick video done handheld on two objects, one with a lot of detailed texture and one with a bit of noise (very dark room!). It's a quick test as I'm going to do a video of these instruments (using a tripod / steadicam and proper mics of course) so got some test grabs and then thought "what the hell" and stuck it together. I still love Cake and can't be tempted away just yet because it works flawlessly even on my Class 6 card.

    I have about a million instruments at home of various shapes and sizes, so endless fodder for videos really.

    If you can't see the video below it's at http:// vimeo.com /37365287 (remove the gaps in the URL first)

  • 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

  • @izash : With these settings you are going to see the bitrate that was needed to encode the content you shot with constant quality. No more no less. The bitrate is spent on demand. If it spent less, don't be disappointed, instead be glad that it didn't need to go bananas on the bitrate and on your card, when the footage was easy to compress with still good quality.

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

  • Thank you @duartix and @Mark_the_Harp. So a bitrate of 25Mbs may be sufficient for high quality video? Should I envy the Driftwood and other mega-bitrate patches or be happy with Cake? Izhar

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

  • Very similar to the world of audio - ie, "If it sounds good, it is good".