@duartix - "I'm just curious on how pure I/B performs vs pure I/P."

If you examine a GH2 AVCHD file with MediaInfo, you'll see it's recorded in H.264 High Profile, Level 4.0 with two reference frames. This means that the encoder will use up to two I or P-frames as sources for macroblock motion vectors when encoding nearby P or B-frames. In the GH2's case, there are only a few practical differences between P and B-frames:

• P-frames can be used as a source of macroblock motion vectors, B-frames cannot.
• B-frames can refer to I or P-frames in the past or future; P-frames only use past frames.
• B-frames can use the weighted average of two different motion vectors in a macroblock.
• Unhacked B-frame quantizer tables are of coarser quality than P-frame quantizer tables.

With unhacked quantizer tables, a video with P-frames will be encoded at a finer level of quality than one that includes B-frames as well. In the Flow Motion Patch, however, I've reassigned the quantizer tables to match both P and B-frame image quality to that of I-frames. As a result, there is no penalty to using B-frames and the improved quality tends to produce larger B-frames than seen in other patches.

In addition, there is an often overlooked P and B-frame encoding issue that Flow Motion rectifies. In cases where no useful motion vector can be found for a particular P or B-frame macroblock, the GH2 will encode that macroblock in intra-mode, just as it would in an I-frame! This occurs frequently in videos that contain rapid movements. These intra-coded macroblocks would look just as good in P and B-frames if only the encoder used the same intra quantizer tables as it uses in I-frames. Fortunately, that flaw was easy to fix with the Flow Motion Patch.

During my testing, I often saw P and B-frames with nearly half their macroblocks encoded in intra-mode. Here's an example of a B-frame from a 24p video. Macroblocks with blue dots are encoded with motion vectors; the ones with red dots are intra-coded.

In interlaced 1080i videos, there is another interesting issue. It turns out that in I-frames, alternatiing horizontal rows of macroblocks are encoded as P-frame macroblocks!

This is no doubt because the alternating P-frame rows are actually an interlaced field that was scanned 1/60th of a second after the initial I-frame field. Evidently, only the first field in each GOP is encoded as an I-frame, with the second field encoded as a P-frame. In Flow Motion's 1080i modes, the 3-frame IBB GOP is effectively treated as an interlaced 6-field IPBBBB GOP. Note that this P-frame can also contain individual intra-coded macroblocks in areas of rapid motion.

Here's the original 24p video, showing how areas of rapid motion correspond to intra-coded macroblocks.

@LPowell Is their a tweak that could be made to restore the superfine detail of the intra patches and keep the quality benefits of flowmotion? File size is not important to me but I like having a max quality setting and a lower version in 24l which gives me in camera playback and spanning, like I have now with quantum beta 3.

I am very happy with qb3 but am enticed by the idea that flowmotion may have better motion rendering?

LPowell, that does look damn good! The motion looks clean.

Lee, use split screen view on streameye, and you'll see its always the case for interlaced video; top field is INTRA, bottom field is predicted.

@balazer - "It improves on Flow Motion by having more consistent frame-to-frame quality (by using P-frames instead of B-frames)"

I don't understand what you mean by this claim, as there is nothing about B-frames that would make them less "consistent" than P-frames. In the unhacked firmware, the quantizer tables assigned to B-frames are coarser than the tables assigned to P-frames. Once this problem is corrected, P and B-frames are encoded at the same quality level.

I'm not sure what it would take to make 1080i with P-frames work in Cake. If you change this mode back to B-frames, the settings you've put in Cake v1.1 will make it a low-bitrate version of Flow Motion. In my testing, I concluded that Flow Motion needed a 100Mbps bitrate in order to produce the highest quality I-frames. And as you can see, lowering the bitrate doesn't necessarily improve stability.

All Flow Motion video modes work as intended, but may fail occasionally on brightly lit test charts at extremely high bitrates. Flow Motion worked reliably with virtually all other types of subjects I've tried. With upcoming versions of PTool, I'll be able to provide customized quantizer tables that will insure reliability under all recording conditions.

BTW, Flow Motion also encodes in what you're calling "constant quality variable bit rate" mode. It uses the standard QP of 20 in all modes, while the new version of Cake uses a somewhat coarser QP of 22 in 1080 modes.

@LPowell, when the GH2 encoder bit rate is under Top and not constrained by frame limits, the encoder is in constant QP mode. Every I-frame, P-frame, and B-frame has nearly the same QP in every block. The encoder is doing nothing to artificially reduce the quality of the frames, even with the stock scaling tables. (maybe this mode is using T0, or not scaling at all - I don't know) Your scaling table settings in Flow Motion don't change this behavior. But for whatever reason, the B-frames don't look as good as the I-frames and the P-frames, even though they have the same QP. I don't know why. But I have seen it consistently in Flow Motion, and in my experiments at different GOP lengths using high Top settings and stock scaling table assignments. How apparent these differences are for a given QP depends on what ISO you're shooting at and how bright the subject is. Sometimes the difference is barely noticeable, and sometimes it's quite apparent.

Your scaling table re-assignments, as best I can tell, only come into play when the bit rate goes above Top.

At a low enough QP in constant QP mode, the B-frames will look good, and it won't be readily apparent that the neighboring I- and P-frames look a little better. That's especially true in Gop3Zilla, for example, which uses a very low QP and high quality in every frame. It's also true in Flow Motion at H100 most of the time, and less often at L50.

I just decided to go a different route, using P-frames instead of B-frames. For the same QP, P-frames match the quality of the I-frames better than B-frames do. P-frames look better than B-frames for the same QP. That's why I can use a QP of 22 and be about the same quality as your QP 20, and have better frame-to-frame consistency.

Using a higher QP makes the bit rate more variable. P-frames are larger than B-frames of the same QP. Part of that I'm sure is due to the lower efficiency of P-frames, and part because the P-frames look better. So whether Cake is more or less efficient than Flow Motion H100, I don't know. You're using a lower QP and I'm using P-frames. Maybe it's a wash. What I know is that the bit rate of Cake is highly variable. Shooting at ISO 1600 with high motion, for example, produces an average bit rate of 40 Mbps. Shooting a detailed scene at ISO 160 with no motion produces 20 Mbps. Above ISO 3200 or so, the bit rate is near 70 Mbps.

BTW, it's very easy to make 1080/60i fail in Flow Motion. I just need to set the ISO high. (no test chart or death chart; just pointed at a wall)

@duartix - "My reasoning is that in the sequence i1 b2 b3 i4, the frame b2 will be mostly encoded in motion vectors from i1 while b3 (which can't refer b2) will be mostly encoded in motion vectors backwards from i4."

True, but there's an additional factor that can make a major difference. Unlike P-frames, B-frames can combine motion vectors from two different reference frames, calculating a weighted average of the two vectors. In your example, this means that both B2 and B3 are encoded using blended motion vectors from both I1 and I4. My intuitive hunch is that the pair of B-frames function as a bi-directional bridge between I-frames, similar to how "tweened" animation frames fill in the gaps in a keyframed animation. In my view, this makes B-frames inherently better suited than P-frames for producing frame-to-frame edge consistency in Flow Motion videos.

BTW, the data overhead of storing motion vectors is the same in B-frames as in P-frames, i.e. there's no penalty for using B-frames. Here's a good overview of how it all works:

http://tech.ebu.ch/docs/techreview/trev_293-schaefer.pdf

A big thank you to LPowell for this amazing patch. I can see smoother motion in terms of edge shimmer, especially with Panasonic and Olympus m43 lenses. Here is my first test of Flow Motion 24H using the Olympus 12mm F2.0. With handheld work such as the following, I would normally see plenty of distracting shimmer with even the tiniest movement. With other patches, I found I could minimize the shimmer with slower shutter speeds--basically replacing edge shimmer with motion blur. Now shimmer is more or less non-existent at even 1/50th second. Needless to say, I'm delighted with the results.

Perhaps your next patch will be called "It Ain't The Meat (It's The Motion)"!

I used your patch on this very basic interview. nikon 50mm f1.4 - good work and thank you

http://vimeo.com/m/36357310

Flow Motion color corrected test shot.

Great bridge shot. +++++.

Any chance it will span on a sandisk 30mb/s at H?

Thanks