So far I'm LOVING this patch, and it might well be my new standard! I've only tested 24H on a Sandisk 30mb/s 16gb card. I have yet to do any systematic test with alternatives, but here are some things I love:

• great quality and no noticeable nasty artifacts or banding!
• fantastic stability: with in-camera playback and sound! yes! (Quantum 100 also gives me playback in camera)
• good recording times per gb --> a 16gb gets you about 21 minutes (about twice as much as Quantum 9vb, but the same as Quantum 100); extrapolate this over the big storage bump with a transcode, and you get a sense of the space comparisons we are talking about here.
• guaranteed spanning on 24L (though yet to try) but I also got it to span on 24H my Sandisk 30 mb/s! (because I wasn't stressing the codec enough at the relevant 4.29gb mark?)
• even if you can't get spanning on 24H this patches gives a healthy 12 or so minutes in that mode which is more than enough for narrative fiction filmmaking long takes!

At a certain point, the gains in perceptible quality vs. costs of storage and loss of functionality aren't worth it to me. Give me some improved settings I can rely on, and let me shoot!! If I need the absolute best quality from a GH2 and don't want to save harddrive space, then it's Q9vb (or X when it's not beta)). For super big projects, I'm just going to rent a RED or an Alexa or whatever. For indie, micro-budget projects or docs, Lpowell's 24H or Quantum 100 at 24H is more than enough.

I guess the one thing that might be a potential short-coming is ETC, which is quite useful for some doc stuff. BUT I'm just basing this on other people's comments and not my own experiments with the patch.

Finally, Lpowell's view that it is the keyframes per second that really matters in terms of motion rendering and not the GOP length per se is fascinating.

Thanks lpowell, fascinating as always

@LPowell exposition and amazing example of inverse engineering. What I do not understand is this: "the keyframes per second that really matters in terms of motion rendering and not the GOP length". To me this is a contradiction. I fully agree with that the key-frames is what matters for good motion compression, but the number of key frames depends just of the GOPs length. The only way of getting more K-frames per second is shortening the GOPs, or there is other? Or are "I" frames different than "key-frames"?.

Just ran some tests of FloMotion vs. Quantum 100 for rendering of basically static scene with some audio in background. I tried to match things by manually white balancing on a card, but there was slight difference in white balance. Also, I accidently bumped the camera before doing the second patch, so the positions slightly changed. It's not perfect, but conditions are basically equal: Same Shutter (40), ISO (1600), and F-stop (4). Film Mode: Smooth: (-2, -2, 0, -2.) Used Mac Screenshot to capture from PNGs from playback of non-transcoded MTS files via VLC.

Interesting findings:

1. @24H: Focus was on the "Illy" silver coffee canister. It's close, but Quantum 100 shows slightly better rendition of some fine detail. I'm talking about pixel peeping at 500% or more. Zoom in on the "Illy" sign to see.

2. @24H w/ ETC: Focus was on the "Kriptonite" orange Bicycle lock. FloMotion actually looks a hair better to my eyes, but this seems more subjective than anything.

3. @720p: Focus was on the "Kriptonite" orange Bicycle lock I believe. FloMotion: same as #2, although it's seems that Sage's NINE patch would, if tested, significantly improve the Quantum settings (at a loss of using any Panny Lenses).

@LPowell has explicitly said that FloMotion isn't aimed at static image quality, so this is not really testing the patch for it's strong point, which is (nearly? ETC @720p being an exception?) full functionality. But I thought it was worth comparing it to Quantum 100 in this regard anyway.

Also interesting that Q100 and FloMo @24H give the same reading of card space on my Sandisk 30 mb/s 16 gb card, BUT they eat up the SD card space differently. For example, a 4 min file on Flo Mo takes up 977mb vs 2.96GB on Q100. HOWEVER, when transcoded to ProRes... they take up about the same amount of space! FloMo gives 3.42gb and Q100 gives 3.63gb. Interesting... seems that you're ultimately not paying a harddrive space price for Q100's slightly better 24H quality, although you are paying for it in terms of SD card space.

@lpowell, I-frames do not "produce" or contain motion vectors. Motion vectors are not re-used between frames. A block in a P-frame or B-frame may contain motion vectors that reference previously decoded frames, not the other way around. Motion vectors are not any more "stale" or less accurate or useful as the GOPs get longer or as you get further into a GOP.

@balazer Let's not be pendantic, I offered this as an inituitive analysis rather than a textbook explanation. What I'm loosely referring to as "motion vectors" are the references to macroblocks in the I-frame that are reused as starting approximations of macroblocks in P and B-frames. Over time, they grow "stale" in the sense that changes in the details of subsequent frames degrade their usefulness as approximations, and require the encoder to spend more bits on encoding the residual discrepancies.

If you'd prefer a more technical discussion, I'd be very interested to evaluate examples of the test footage on which you're basing your modest boast that "Cake beats Flow Motion L50 under all other conditions [except for for scenes with low motion, low noise, and high detail]."

Here's a GOP9 example with P and B frames.

1 2 3 4 5 6 7 8 9 10

I B B P B B P B B I

Frame 4 references frame 1. Frame 7 references frame 4. Frames 2 and 3 reference frames 1 and 4. Frames 5 and 6 reference frames 4 and 7. Frames 8 and 9 reference frames 7 and 10.

Note that each P-frame references a frame 3 frames earlier, and the B-frames are referencing frames 1 and 2 frames away. If you increase the length of the GOP while maintaining this same pattern of B-frames (2 adjacent B-frames), nothing changes about how far away the references are. Of course every predicted frame depends on an I-frame, but it doesn't matter how many levels of reference indirection there are between a predicted frame and the I-frame that it depends on. It doesn't matter that you have several levels of reference indirection or a large frame distance between frame 9 and frame 1: the extra levels of indirection don't make frame 9's reference to frame 7 any less relevant or useful than frame 3's reference to frame 1, for example, and it doesn't mean that frame 9 will need to be any bigger than frame 3.

That's because the references are relative to decoded pictures. Frame 4 can contain all of the quantized coefficients necessary to properly represent frame 4 with the same quality as frame 1, even though the frame 4 may be very different from frame 1 and the motion vectors may not predict frame 4 very accurately. Same for frame 7. Same for every predicted frame. Errors do not accumulate as the levels of reference indirection or the frame distances increase, because each frame contains the necessary information to correct for the errors that reference frames may contain, and for the inaccuracy that prediction using motion vectors may produce. The number of bits required in frame 9 to correct for the errors in frames 7 and 10 and for the inaccuracy of prediction from frames 7 and 10 depends only on how much error frames 7 and 10 contain and on how different frames 7 and 10 are from frame 9. It doesn't matter at all how different frame 9 is from frame 1. You can use GOP99 and achieve the same quality as GOP6 or GOP9, and benefit from motion estimation in exactly the same way, with the same efficiency over the length of the GOP.

@querty123 You wrote: "HOWEVER, when transcoded to ProRes... they take up about the same amount of space!"

That's to be expected. ProRes is a VBR codec, but with a very narrow range of "V", other than H.264 aka AVCHD.

@Nino_Ilacqua The second part is flowmotion? I'm currently using Driftwood 9B and steadicam shots is so choppy due to motion not so smooth. Looking forward to trying flowmotion.

@tmcat @LPowell Yeah, I was going to show it here, but wasn't fast enough! :D We applied to it a little bit of curves here and there, because it was sunset and light was changing from one minute to another but it's pretty much the same. Experienced some problems with macroblocking in the sky (wasn't noticeable until applying curves), but besides that it was great. We got there, asked that guy and shoot like that, it was the third time trying our GH2 and I must say it's amazing. Thanks to all of you, LPowell for the patch and specially @Vitaliy_Kiselev for all the effort you put into this! A huge thanks goes to our friend @atticusd as well, who brought us into personal-view and the awesome gh2 world!

@tmcat Absolutely, there's no need to apologize! What I like the most of this forum is the speed of information, and I usually browse the latest gh2 hack videos on vimeo as well, so I'm glad you found this video. I too think this patch is going to be huge, we tried 24H and thought it was better than Quantum100 for portraits, but then again this is all so subjective...

@balazer -"Of course every predicted frame (P-frame) depends on an I-frame, but it doesn't matter how many levels of reference indirection there are between a predicted frame and the I-frame that it depends on... Errors do not accumulate as the levels of reference indirection or the frame distances increase"

This is indeed how an AVCHD encoder is designed to work in theory, and professional Blu-ray encoders demonstrate how remarkably well it can be done in practice. If you download my 3-way Patch Test MP4 file from Vimeo and examine it in Elecard Streameye, you'll see a good example in action:

I rendered this H.264 video at 50Mbps after cropping the 1080p images down to 720p. The MP4 uses a 33-frame GOP and achieves QP levels of around 6-12. As this is finer quantization than any of the three patches I tested, it does a very good job of rendering the three clips' original image quality without adding perceptible artifacts of its own.

With the GH2's AVCHD encoder, however, there are two significant ways in which it falls seriously short of the ideal predicted by theory. When a P-frame is built out of motion vectors derived from a previous I or P-frame, the encoder is making a copy of a copy. If the P-frame quantizer tables were as fine as those used in I-frames, multiple generations of copies would suffer little degradation. Unfortunately, the GH2's P-frames have used significantly coarser quantizer tables and the errors are in fact larger in P-frame sequences. While these errors are corrected with encoded residual data, it uses up more bitrate to do so as the copies are more degraded. This is an an example of what I mean by motion vectors going "stale".

The other shortfall of the GH2 encoder is that it must work in real-time and cannot indulge in extensive motion vector searches or anticipate the bitrate requirements of frames that have not yet been recorded. This restricts its choice of motion vectors to those that lie close at hand. That is why I believe short-GOPs are inherently better suited to real-time motion capture than long-GOP formats. Short-GOPs dramatically simplify the encoder's motion tracking tasks, eliminate the long-GOP sequence of degraded P-frame copies, and automatically keep the motion vectors fresh. In practice, it appears to work with remarkably high quality at moderate bitrates in the Flow Motion Patch.