Thanks for posting your decoding results, the differences between Pavtube and ClipWrap renderings are quite noticeable. To answer your question, there are no metadata tags I'm aware of that would indicate patch settings used in an original MTS file. The best tool for examining these files is cbrandin's StreamParser.

There are several technical issues to bear in mind in evaluating test shots of this nature:

1. The GH2 is a consumer camera that has only a limited degree of gamma control. In particular, it lacks a pedestal setting, making it impossible to correct its nonlinear handling of shadow detail.

2. The GH2's low-level noise ramps up noticeably beyond ISO 1600, and further obscures its shadow details.

3. The 8-bit encoding of AVCHD macroblocks has a brutal effect on near-black shades, rendering them with exaggerated saturation and much cruder posterization than brighter colors. This where the subjective quality of different decoding, chroma smoothing, and noise reduction algorithms can make a noticeable difference.

The bottom line is that the post-production quality issue you're exploring is to a large degree a salvage operation. To suit typical consumer applications, the GH2 is designed to crush its noisy near-black details and devote most of its bitrate to encoding bright, well-exposed images. While a good hack can improve the GH2's overall performance, we still have no way to alter the camera's built-in gamma curves, which is the primary factor that determines the perceptual quality of its shadow details.

@jpbturbo Actually, the reports I've read are that it's Premiere Pro CS6 that has a problem, and not CS5 or CS5.5. The traces of the effect that I see in Johannez' Pavtube footage are elusive and occur sporatically on just a single frame at a time. The fact that the effect disappears completely in the ClipWrap footage is very provocative, and strongly suggests a decoding error in the Pavtube footage. The frames where it occurs look fine on their own, and do not contain any blatant digital artifacts. It's only when you compare frame-to-frame macroblock levels.

@lpowell I definitely get the "digital rain" in premiere pro CS5, I haven't tried AE yet.

AME can transcode the footage to DNxHD just fine however so it's just how premiere reads the .mts files.

I'll see if I can post some samples later this week.

@lpowell I just checked and some earlier footage that I had filmed using one of Nick's drewnet patches does the same thing in my copy of Premiere Pro CS5.

Edit, some CM Night footage at 60fps also has some corruption in PPro but not in AE :(

@radikalfilm AME transcodes to DNxHD just fine for me.

You might also try using the "AnotherGUI" front end for ffmpeg to transcode to prores and see if it can transcode without the rain.

@radikalfilm "The "digital rain" caused by low light exposure nearly ruined 80% of my short shot on Flowmotion 2.02. The rest was shot on Valkyrie, which rocks in any light"

Interesting observations. Perhaps you could back them up with pertinent details from the production (workflow, settings etc.) and example footage comparing the two hacks.

@radikalfilm

I hardly have time to reply to this as I'm on a tight deadline with finishing post. That's why I said it's too late for me to learn about a workflow (as presented by the thread starter) which avoids the "rain" in Flowmotion.

Up to this point, reports of this post-production decoding flaw have only been able to provide fragmentary and inconclusive evidence. It's been challenging even to unambiguously describe the visual nature of its appearance to those who don't already know what to look for. From your account, it sounds like you've spotted it frequently in your footage. Any standout examples you could make available for download in their original MTS files would be greatly appreciated.

@LPowell Do you have CS6, and if so, have you seen what happens to the footage? I like your hack, but I cannot import Flowmotion 2.02 files directly in to Premiere or After Effects CS6 without this "digital rain" appearing. Yes, it is a flaw of CS6 and not the hack, but it is definately there. Here is the link to my tests. If people want to see the effect being discussed, they should download these examples from Vimeo and examine the footage from the two CS6 example. The original MTS file is there too.

http://www.personal-view.com/talks/discussion/comment/93108#Comment_93108

@lpowell

I'll put some .mts files up on my site later this evening.

@Johannez

So, to sum things up, apparently the "digital rain" can appear in underexposed area's shot by a flowmotion-hacked GH2 and not converted by ClipWrap or After Effects, but by something else... would that be safe to say?

Yes, but apparently @jpbturbo has now seen similar artifacts appear in Premiere-converted footage using two of Driftwood's patches as well. My suspicion is that this is a latent flaw in certain decoders that is sporatically exposed by some specific combination of H.264 encoding parameters. While the patched GH2 does not stray outside the limits of the H.264 encoding format, it's impractical for a decoder manufacturer to test and verify every possible permutation of those parameters, especially if they don't have samples of high-bitrate test footage available.

@LPowell All files have been re-uploaded. You can now see the various program comparisons. The original MTS file is available for download.

http://www.personal-view.com/talks/discussion/comment/93108#Comment_93108