@Ralph_B - "This is the way an interframe codec works. It first throws away information the eye can't detect. And one thing the eye can't see is low contrast detail in rapid motion."
Yes and no. Throwing away detail is not good if avoidable, and the new options are making that more avoidable. Amazing what we're gleaned from your tests, just awesome, and enough thanks cannot be thrown your way.
Further analysis of the HDMI vs AVCHD ISO 160 tests:
I ran the four AVCHD clips through Stream Parser to see if there was a correlation with what I was seeing with my eye. Indeed there is! These pictures are from the static portion of the clips.
My suspicion that 66M AQ3 is superior to 66M AQ2 is confirmed by the larger I-frames. We also see that 66M AQ3 is essentially the same as 132M AQ2, but at half the data rate.
It's true that 132M is the king for holding detail in motion, but it's also true that 66M AQ3 is the king at the 66M data rate, and is superior to everything below it. For this reason, I feel it's important to make this setting as stable as possible. For many people, 132M is just too high of a data rate.
I love your testing. Is the 66M AQ 3 test my 66M settings with AQ just raised to 3? That seems like too big a difference between the two 66M tests. Is there any possibility that lighting changed? Or, is it possible that the AQ setting box was not checked with the AQ 2 test? Or, maybe the 66M AQ2 shot was slightly out of focus? I've seen differences with AQ settings at 66M, but never anything that dramatic - the video bitrate at 66M AQ 2 in your test is considerably below 66M.
Ah, you're right, the exposure DID change! You can see it the pictures at the top of the page. But in answer to your question, yes, the AQ3 is your AQ2 with only the AQ changed.
Well, I guess I'll have do some more tests, ARRGG!!
No need to change buffers. Determining the balance between motion and detail is exactly what the AQ setting is for. Nothing mysterious here - it's just a matter of striking the balance appropriate for your needs. Now, setting a high AQ value does stress the codec more - too high a value can cause stability, playback issues, etc...
For those of you who want to use 66M AQ3, a word of caution. I've uploaded the original MTS file to Sendspace. Look what happens at 22 seconds. You do not want this happening on your shoot! And the scary thing is, there was no indication in the viewfiner this was ocuring. BTW, I was using a Sandisk Extreme class 10 card.
Wow, that's strange. It's not just at 22 seconds, all the fast pans show it. It's behaving like it's interlaced, rather than progressive - sort of. Somehow, frames are being combined. It might be worth trying to repeat this, maybe (hopefully) it was just a glitch. You shot this at a high shutter speed - yes?
In the manual for the GH2 Panasonic has a strange description of 24p mode - something describing double images, or something like that. It was pretty strange - I wonder if this is what they mean?
I think I may know what is happening. When P frames run out of bandwidth (or think they have) many macroblocks end up being "skipped", which means they are not encoded and the contents of prior P or I frames are used. It looks like enough macroblocks were skipped to create this ghosting effect.
I downloaded the file and will look at it to see if this is indeed what has happened.
And just a note, it is not an interlaced look. It has a similar ghost trail look, but there is no interlaced alternating line stuff, and what's more, upon pausing the footage, there is no apparent double image. This would seem to support Mr. Brandin's hypothesis.
Oops - forget what I said before - I made a mistake with my editor setup - sorry. Now when I look at it it seems fine - what am I looking for at 22 seconds?
I see something fairly subtle when the motion stops - but nothing extreme. I'm stepping frame by frame with an editor looking at it. One would expect a little of this if motion stops suddenly between I frames because the increase in detail, because you stopped, won't happen significantly until the next I frame. But you would see this in all modes and bitrates to a certain extent.
Have you dropped this into an editor? Maybe this is just a quirk with some players because they are having trouble keeping up. Can you point me to a frame number where the problem exists, and then the frame number where it goes away?
What software are you using to decode the H264? I've tried two decoders, ffdshow and CoreAVC. Both show severe breakup at 22 seconds. It's not something you would miss.