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

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

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?

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

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.

@Mark_the_Harp Thank you Mark!

@_gl Thanks!

This is my first test movie with the new version of Vitaly's GH2 hack. I used Balazer's Cake 1.2 patch and the results are beautiful to my eyes. The cars' motion is so smooth, it almost looks like slomo. The GH2 is one amazing camera, made better by some wonderfully talented people.

What I think is that some software applications know how to detect that the PsF video of some cameras is actually progressive. But I contend that it's not because the videos are properly flagged. There aren't any flags in h.264 to say that the video format is progressive even though the encoding is interlaced. An h.264 stream is interlaced or progressive, period. There's only one flag in the stream. The software is probably using some trick, like noticing that the video is encoded all as frame pictures instead of field pictures.

That author is keying in on the fact that some software does what he wants for the PsF video of some cameras, and doesn't for the PsF of other cameras. That's what he's calling benign and malignant. But it's not the video's fault that some software doesn't do what he wants. PsF means the video stream is interlaced, and will be treated as interlaced by software and hardware. That was entirely the point of PsF: to take progressive video and make it interlaced, so that it would work with equipment just like interlaced video does. Turning PsF back into progressive is something that a human, with knowledge of the fact that the frames originated as progressive, has to do.

@lpowell, there is no way to properly flag PsF as progressive in AVCHD. PsF is progressive video that has been converted to interlaced and encoded as interlaced. It is interlaced video, as far as any hardware and software are concerned. The notion of "benign PsF" is misstated.

@duartix I'm slightly out of my depth here, but that's never stopped me before! I set QP to 20 in pTools and here's what the stream info says for a ISO 2500 clip in weakish artificial light (slight but not horrible image noise) with the Panasonic 14-140 lens at 24H. This was a mix of still and then shaking the camera violently.

I must say, the pictures look great so really that's all that matters...but if any values strike you as interesting I'd love to know. Happy to test anything out...

Stream info:

video stream type AVC | resolution 1920x1080 | profile:level High:4.0 | aspect ratio 16x9(1:1) | chroma format 4:2:0 | interlaced no | frames count 645 | duration 00:00:26.860 | frame size max 653 376 / avg 399 444 | avg/max (I) : 551 341 / 653 376 | avg/max (P) : 323 495 / 448 128 | avg/max (B) : 0 / 0 | min : 195 072 |

framerate declared : 23.976 / real : 23.976 |

bitrate type : VBR / bitrate declared : 71 681 024 |

bit allocation max 89 914 960 / avg 76 616 696 / min 70 151 600

Picture info:

mb count : 8 160 | picture size : 2 836 898 [354 612] | transform coeff size : 2 659 245 [93.74%] | mv size : 44 460 [1.57%] | max mb size : 975 [1684] | max qp : 20 [0] | min qp : 20 [0] | max mv x : 281 [3948] | max mv y : 114 [3710] | min mv x : -319 [3356] | min mv y : -119 [176] |

As said by @Meierhans 24p looks mostly sharper and has a lot less blocking in the shadows.

@Meierhans

and what´s with the "Int" from Intel? They are more sharp in 30p. I think, that are only sensor reading tolerances.