@balazer, my low-GOP/motion comment wasn't aimed at you or Cake; it's my first test with any low-GOP patch (yes I said 'patch', sue me) so I was just commenting on that ... but blow me down, I do see the difference now!

While Chris66 definitely holds onto more detail during motion (see another slow-pan example attached, note the grass & path grain), it also produces more synthetic motion, a kind of artificial motion blur. It is subtle & easy to miss, but now I see it I want low GOP.

That Chris66 gets more detail is obvious though, a long GOP with B frames is more efficient, so for the same bitrate you can store more detail. It bugs me most on the grass.

I'm also aware of (and hate) B-frame pulsing, but I haven't really seen that with Chris much, across a range of footage - take for example this frame-stepped water burst from my 3D footage (2 cams overlayed into a 3D red/cyan anaglyph). Plenty of detail yet no obvious quality differences between frames (actually I can see a very slight variation, but you'd never notice it at full speed).

But that's only with my style of footage, do you have a good counter example? And considering that Cake spans (not tried yet) and manages close quality with such a small GOP and no B's but similar bitrate is pretty amazing. And it scrubs a bit faster too. I think I'll tweak the quantizer down as you've suggested, and run another test when I get time.

Hope this is a useful observation, for interest anyway:

In reply to someone who commented on vimeo, I was wondering how the "time remaining" count might work, as it always seems to start at a set time. When first playing with Cake, I noticed the time remaining count seemed to be running at a non-standard speed.

I just investigated this furher: I did two shots, one with a LOT of motion and one with blurry, static detail.

In the viewfinder, assuming you've got all display items visible, with all types of movement you will see the seconds (ie duration) count up normally.

However, the "time remaining" counter underneath it runs more slowly with low detail, low-motion scenes - counting down two seconds for every three that you actually shoot. In fast scenes, the two counters are almost (but not quite) in sync. That makes sense - it suggests to me that with fast motion you are getting near the upper limit of bitrate, and at low motion you get about 50% more recording time. Probably a bit like when you're in a hurry, and time seems to move faster.

That also makes me wonder (am I right?) that the time remaining counter bases its calculation on the card size and some sort of maximum rate limit set by the patch.

And if that's true, is this maximum bitrate related to the "red line" in Elecard buffer analyzer" (see below)?

@Mark_the_Harp

Even though I suggested it, I've never used Elecards's software so I don't can't help you in that matter. But what min/max block quantizers are you getting with QP=20?

@balazer:

Thanks for your new settings. I compared HBR_30p vs. 24H. I do not see any differences, do you? I hear people say that HBR is crap???

@Meierhans

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

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

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

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

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.

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.

@_gl Thanks!

@Mark_the_Harp Thank you Mark!