@5thwall Very nice work mate. Really interesting to watch and looks great too.

@driftwood, can you tell me more about Quantum 100 is that's okay with you? :)

@5thwall - Wow, just a great little doc. We're in SF at the moment, but may have a job in LA next month. If so, I'm heading over to buy some vinyl! Good stuff all the way around, man... broadcast ready.

@LPowell

I'm an admirer of your work.

"Sorry, but there's nothing special about AVCCAM, it's just an early version of AVCHD that Panasonic chose to implement in their pro video cameras."

I am absolutely certain that this is a perfectly reasonable response from someone with your background -- someone who has been staring at encoding data for months. From the perspective of the broadcast community -- I can report that there are at least two major TV stations in the Washington DC area that use those external Panasonic AVCCAM recorders for broadcast, and a series of articles/blogs from relatively serious producers around the world who describe outstanding results -- at least two of whom couldn't differentiate it from AVCintra100. And, as computers and post applications have advanced over the past three years, AVCCAM has been very gradually embraced by serious users for serious purposes. Whatever the specifics of the encoding behind AVCCAM -- the bottom line is that it's a LongGOP format that a range of serious people take seriously.

"A constant bitrate is useful for broadcast and streaming media, but offers no technical advantages in video capture applications."

Respectfully, this is a very highly debatable position on a range of levels. Almost all higher end production solutions offer a CBR option, and there are many out there who have a series of issues with VBR at capture. Again, you may be responding relative to your experience, and I'm certainly not here to argue anything about the GH2 with you. Relative to more generalized producers -- yeah -- CBR can matter.

Now -- AVCCAM is not CBR, and I never suggested a CBR version of AVCCAM. What I requested is something that remains constant between 63 and 72 Mbps -- exactly three times the bit rate of AVCCAM (meaning it doesn't drop below 63).

" Long-GOP formats are likewise effective for commercial delivery formats such as DVD and Blu-ray, but are not optimal for real-time encoders with constrained resources and time frames."

Well, yeah, and no one disputes this in a general context. If all things are equal, sure, you pick intraframe over LongGOP. But, two things. First, LongGOP is a hell of a lot more efficient in terms of file sizes, and second, post production technologies have greatly evolved over the past decade to make LongGOP streams a viable production option. Beginning with the old "DV" and continuing all the way through to AVCCAM and NXCAM -- especially an NLE like Premiere Pro can work very, very seamlessly with LongGOP and deliver to any broadcast and/or distributor standard.

But, the intra vs. long-gop discussion really doesn't relate to my request for an AVCCAM clone with the bitrate multiplied by three.

Again, I am an admirer of your work and I'm rooting for all of you guys who are not only making a unique camera, but actually changing the marketplace.

@cosimo_bullo @fancydancer Thanks! It was a joy to shoot - more so because of my rockin' GH2. And looks like it's doing it's job, because a lot of people say they want to go check out the stores after seeing it :-).

Regarding DOF, glad you noticed. I was pretty specific about not going overboard with it.

Looking forward to the new PTools and next crop of patches. Should be an interesting couple of months.

@onionbrain The professional AVCCAM tools used in the broadcast industry have certainly established their value in that context. However, AVCCAM was designed and optimized for videotape equipment working with interlaced 60i transport media. These systems impose very different technical contraints on real-time video recording than do SD cards.

There are two technical factors that make CBR recording advantageous for broadcast applications. The HDV tape mechanisms work at a constant tape speed, producing a constant bitrate. Likewise, video broadcast channels are allocated a fixed amount of bandwidth, which makes CBR a natural fit.

SD cards, however, work under neither of these constraints, and CBR recording will impose an inflexible bitrate that is either insufficient or wasteful for any particular subject matter. AVC encoders are designed to produce VBR bitstreams and work most efficiently when allowed to vary their bitrate to accommodate the constantly changing demands of video recording. And with the GH2's AVCHD encoder, there's no way to force it to maintain a constant bitrate "between 63 and 72 Mbps" or any other number.

As for the long-GOP versus Intra debate, I've found that there is a measurable, objective difference. With a standard AVCHD encoder, P and B-frames are recorded at a coarser level of quality than I-frames, and this fact alone gives Intra encoding a static image quality advantage (as long as it has adequate bitrate for the subject matter). In addition, Intra encoding is not subject to the motion artifacts that can occur when long-GOP encoders run out of bitrate. (Intra encoders will instead produce coarse macroblocks when they run out of bitrate.)

As you point out, Intra encoders are extremely inefficient and routinely waste large amounts of file space. My conclusion is that the optimal SD card recording formats are short-GOP encodings that produce 8-12 keyframes per second. To maintain Intra-frame quality levels in short-GOP recordings, howeve, it's vital to encode P and B-frames with the same quality as I-frames. This is what I was able to do the my Flow Motion patch, and at this point, the GH2 is the only available videocamera capable of being configured to record in this manner.