How Long Has This Been Going On?

While it seems like forever since the GH2 was first hacked in a hardcore tour-de-force by Vitaliy Kiselev, it's actually been just six tumultuous months. During that time, an overwhelming amount of GH2 research, experimentation, and testing results have been shared by numerous contributors to this and other websites. Athough I contributed a 100Mbps MJPEG 1080p patch in the early days, I have not previously released a patch for any of the GH2's AVCHD video modes. One of the main reasons has been the wide variety of patches that others have already developed for the GH2:

@cbrandin: 44Mbps AQ4 and 66Mbps AQ2 patches with the standard 12-frame GOP.

@driftwood: Quantum 150-176Mbps 24p Intra-frame patches for max image detail.

@bkmcwd: 154Mbps 24p short-GOP patches for maximum I-frame quality.

@Stray: 88Mbps AQ2 24p patches using the standard 12-frame GOP.

@Ralph_B: Sanity long-GOP high-quality, moderate-bitrate patches.

@GH13Timelapser: Low-frame-rate MJPEG patches for time-lapse videography.

These patches all produce excellent results for the specific purposes they were designed to serve. Unfortunately, the GH2 can make use of only one AVCHD and one MJPEG patch at a time. What makes this severely limiting is the wide variety of video modes and unique features that are packed into the GH2. For a patch developer, one of the most difficult challenges has been how to optimize performance of the GH2's most popular video modes without crippling or destabilizing the rest of its modes and functions. Here is the full list to consider:

Always Room for One More Mode

• 24H & 24L modes: 1080p @ 24fps

• FSH & FH modes: 1080i @ 50fps PAL & 60fps NTSC

• SH & H modes: 720p @ 50fps PAL & 60fps NTSC

• 24H & 24L 80% Slo-mo: 1080p @ 30fps

• HD mode: 16:9 MJPEG mode in 720p - 1080p resolution

• VGA mode: 4:3 MJPEG mode in 480p - 960p resolution

• Extra Tele Conversion mode: digital zoom in all modes above

With both NTSC and PAL, I count 14 different video modes, and that doubles when you throw in ETC digital zoom mode as well. By comparison, the GH1 had ten PAL and NTSC modes, but its H and L modes were merely low bitrate versions of 720p mode. If you consider how long it takes to fully test a comprehensive GH2 patch in all possible combinations of video modes, you may get an idea of how I've been spending my free time these past few months...

The Great Intra-mural Debate

In the early days of GH2 patch development, an unexpected debate emerged around the AVCHD encoder's use of P and B-frames. As with the GH1, the GH2 encodes video in fixed-length sets of 12-30 frames, each called a "GOP" (Group Of Pictures). Each GOP starts with a self-contained key frame called an "Intra-frame" or "I-frame", followed by partially-encoded difference frames called "P-frames" and "B-frames". While I won't digress into much technical detail here, P and B-frames provide more compact compression than I-frames, but with debatable drawbacks in image quality and motion tracking. One of my early GH1 patches introduced the concept of an ultra-short 3-frame GOP for fast motion-tracking in 720p30 videos. While this sparked some debate on its effectiveness at the time, it was nothing compared to the short-GOP crusade that emerged with the GH2.

With an unhacked GH2, its most popular 1080p24 video mode uses a 12-frame GOP, containing I, P, and B-frames, at bitrates up to 24Mbps. This orthodoxy was first challenged by @kae with his 66Mbps 3-frame GOP patch that worked with the initial GH2 version of PTool. The effects of such a short GOP on image quality and motion rendition were heatedly discussed, with advocates claiming that long-GOP P and B-frame image quality could never match that of I-frames.

The debate simmered for months, seemingly at a stalemate, when a completely unprecedented development blew everything away. After much experimentation, Nick Driftwood discovered a technique that could eliminate P and B-frames entirely, producing videos with 1-frame GOP's that contained only Intra frames, at bitrates up to 176Mbps. The resulting videos packed a huge amount of data into each I-frame, for maximum image detail at the cost of equally unprecedented storage requirements. Since the bitrates were far too high for AVCHD file-spanning to work, the maximum duration of each take dropped to around 3 minutes per 4GB of SD card storage. Any doubts as to whether high-bitrate Intra-frame encoding really produced better image quality were soon laid to rest by Ralph_B's brilliant series of tests comparing driftwood's results to direct HDMI frame grabs.

Although GH2 Intra-frame videos can be recorded at bitrates lower than 176Mbps, image quality is inevitably reduced as well. This is the reason P and B-frames were designed into the GH2's AVCHD encoder in the first place: to reduce video bitrate to the point where 4GB file-spanning can work without noticeably degrading image quality. But somehow this goal fell short, because the stock GH2 clearly cannot match the quality of 176Mbps Intra videos.

GH2 Quantum Mechanics Revealed

Those familiar with video encoder technical details know how the GH2's AVCHD encoder works: it compresses video data by storing it in coarsely approximated data formats. It does so using cleverly devised tables of "quantizers" that slice and dice the data without visibly degrading it. Soon after the GH2 was hacked, Chris Brandin worked with Vitaliy Kiselev to develop a custom patch that would automatically boost quantizer quality at increased bitrates. He then used these "AQ" patches to develop his classic 44Mbps and 66Mbps patches, combining enhanced quantizer quality with moderate bitrates, while retaining the GH2's standard GOP lengths.

While the AQ patches provided important pieces of the GH2 puzzle, they were designed to work properly only with long-GOP encoding, not on ultra-short 3-frame and 1-frame GOPs. At the next layer deep within the encoder lie the actual quantizer tables used by the AVCHD codec - the core of the compression engine. After much research into the firmware, Chris extracted these tables into a spreadsheet, providing for the first time a complete overview of the encoder's inner workings. It was after I studied these tables in detail that I discovered the reason why P and B-frames had never looked as good as I-frames.

Panasonic designed the GH2 as a consumer camera using the limited 24Mbps bitrate dictated by the AVCHD standard. For this reason, their top priority was not achieving the highest image quality, but compressing the video data into the smallest amount of file space. To accomplish this, they minimized the size of P and B-frames by using significantly coarser quantizer tables to encode P and B-frames than they used on I-frames. It was no wonder that Driftwood's strategy of eliminating everything but the I-frames improved image quality!

Fortunately, Vitaliy had the foresight to hack the location of the GH2's quantizer tables, providing patches to reassign the tables used by I, P, and B-frames. In one fell swoop, I was thus able to optimize the quantizer tables for all three frame types, matching P and B-frame image quality to that of I-frames. This provided the key to combining Intra-frame quality with short-GOP motion tracking and compression efficiency.

Here is a set of sample videos shot at ISO200, 1/60 sec, f4.0. These clips show how Flow Motion produces smooth, continuous motion pictures with minimal flickering, even at 24fps.

Flow Motion 24H 1080p24

Flow Motion SH 720p60

Flow Motion MJPEG HD 1080p30

Unfortunately, Vimeo seems to be unable to display interlaced 1080i60 videos. However, you can still download the original Flow Motion FSH 1080i60 MTS file from its Vimeo page.

The last few days I felt there was a silent revolution in the works, it is only now that I see how deep it was... and how much more test work lies ahead. Thanks for your post, it should be made into a sticky because it's a real compass in this sea of patches that this site has grown into.

@LPowerll Brilliant writing, man. I enjoyed reading it.

@LPowell Your description of the process which brought you to this patch is really a "Hack History" and it deserve a bold place into the wiki space!!!

I also have to agree on your writing style, you have taken a fantasticly complex situation and made it into a novel that I can't wait to hear more about.

The idea of P,B frames using a coarser table makes me wonder if it was done for performance reasons.

Good read, can't wait for the patch.

@driftwood Thanks for reminding me of kae's seminal work. I revised my account to reference his pioneering contribution to short-GOP patch development. I'll be making further updates as my work schedule and weather conditions permit...

@Hallvalla While I too am eagerly anticipating the upcoming version of PTool, I'm also aware of how complex a challenge it is to track down the dozens of patches that need to be updated to support the v1.1 firmware. I think we can rest assured that Vitaliy will announce its release as soon as it is complete.

@ehr I plan to upload patch docs and Stream Parser charts tonight after I get off work. Hopefully I will have time Wed morning to edit and upload sample frames and videos.

P and B Frames at the Quality of I-Frames? I'm curious... and can not believe it :-D

@fatpig Matching p frames or b frames to i frames size has already been done ages ago if you look at the Driftwood GOP3ILLA patches in the patch vault.

Thanks @LPowell for your dedication and for sharing with the rest of us. Your stellar GH1 reputation about the thoroughness of patches has just resurrected here. I look forward to your patch and your continuation in the posts at the top of the thread... Al