U DA MAN!!!

I'm a little slow. What is this supposed to be indicating? Is this a frame grab from the HDMI output or something?

Chris,
Thank you for posting this. I read your post several days ago regarding this test and thought it was an excellent idea.
As I mentioned earlier, this topic seems to come up with evey damn video camera that hits the market.
thanks again!

Do you have a turntable? This is not a difficult test. Just make sure you set your editor to native 23.xxx mode. Shoot a spinning record and look at the rotation at each frame.

High shutter speeds might cause a judder of another kind, just not actually a cadence problem. With high shutter speeds you get much more detail and the codec can run out of steam toward the lower part of the frame - especially with P and B frames. In that case the codec will simply skip encoding macroblocks because it has run out of bandwidth, and what you'll get is whatever was in the last frame, or in some cases the last I frame, or mud in the case of I frames (in extreme cases). Somebody posted a remarkable video a while back showing this. It was a video of grass waving in the wind and water flowing in the lower part of the frame. The grass looked great, but the water stuttered along at 1/2 second increments. The water wasn't being properly encoded for a couple of reasons - but 90% of the reason was because it was in the lower part of the frame (the other reason was because it was much lower contrast than the grass). If you consider that one of the side effects of low GOP is to starve frame bandwidth, it could be very possible to get this effect unless you are capturing at extremely high bitrates. I don't think this can be tested with a turntable, though - not enough detail in the right places.

Chris

@Chris

Thanks for this cadence test. I just haven't been seeing the 'judder' problem like others except on certain shots and the so called 'judder' is exactly what I've seen with 35mm over the years when we (usually unintentionally) pan across something detailed while following NOTHING moving with the pan in frame. I saw three films in the theater this weekend and intentionally looked out for shots like this and there were only a few, but each time there was, I saw the "judder" - it's just inherent in the frame rate, has been for decades, that's why we try to avoid medium speed pans without following anything in frame. At high speed you just don't notice it (whip pan) and at slow speed you usually don't notice it. The first time I directed some second unit for a fairly well known director and did a medium speed pan of a city block while following nothing moving the director hit me in the back of the head during dailies and told me never to do it again because it strobed. Nature of the beast.

I personally never thought the frame rate varied that much. I don't think the flickering has do do with evenness. I also only notice it when comparing the GH13. The GH13 just seems a little smoother. I can test it with my superclock, but even if there is a slight variation I don't think it would account for the effect.

@chris
"...and the codec can run out of steam toward the lower part of the frame - especially with P and B frames. In that case the codec will simply skip encoding macroblocks because it has run out of bandwidth"...

I understand what you are saying about running out of bandwidth in the lower frame, if the upper part has used most of the available bandwidth, but during the slow zoom towards the logs, where the upper grass detail moves out of frame, there is NO improvement in the details of the running water, the log or the remaining grass. It's still blocky and jerky. The following shot is much better. Strange. Could there be something else going on to cause this?

A lot of things can be causing this. I admit that I simplified the explanation a little. AVC codecs use a number of strategies to determine how to encode macroblocks, including:

Using neighboring macroblocks as references - this is intra encoding. I frames use this, P and B frames can use this.
Using macroblocks in previous frames as references - P and B frames can do this.
Using macroblocks in later frames as references - B frames can do this.
Using macroblocks in previous frames that are shifted in various directions (motion vectors) as references - P and B frames can do this.
Using macroblocks in later frames that are shifted in various directions (motion vectors) as references - B frames can do this.
Skip encoding the macroblock and just use motion vectors based on previous frames - P and B frames can do this.
Skip encoding the macroblock and just use motion vectors based on later frames - B frames can do this.
Code macroblocks using lower or no detail (macroblocking, or mud) - all frames can do this.
Don't do anything with a macroblock - P and B frames can do this.

The codec works by estimating how much bandwidth it can use at any time and by trying to predict how macroblocks should be encoded. Also a quality comparison test is used. The codec will try to determine the lowest bandwidth demand from the techniques listed above by trying them all and settling on the one that meets quality criteria with the least number of bits. If the quality metric can be met without using all available bandwidth the frames simply come out smaller and the bitrate goes down. If the opposite happens, however, the codec will begin making sacrifices in quality in order not to exceed the allotted bitrate. The result is that the quality can vary in different portions of a single frame, usually meaning that the upper part of the frame is better quality than the lower. It's all very complicated so there isn't one clearly identifiable artifact. For example, motion vectors don't consume much space. If the bitrate reduction strategy that yields the best result is skipped macroblock motion vectors, rather than low-detail encoding, the codec will use that. Both can look bad, but in different ways. In a frame where these compromises have been made you might see the effects of both in different parts of the frame.

Chris

That would be nice. Your video is one of the best examples that shows the various things that can happen when the codec fails.

Chris

@Cbrandin

Would you rather have a P frame or I frame if both are the same size? A lot of the videos I have taken that have waving grass and water like the one shown above have P frames and I frames that are the same size. I was wondering if that is a good thing or a bad thing? Would it be better to reduce the GOP value and eliminate the P frames if the I frames stay the same size?

@cbrandin "The codec will try to determine the lowest bandwidth demand from the techniques listed above by trying them all and settling on the one that meets quality criteria with the least number of bits."

Thanks for the succinct overview of macroblock encoding strategies. I'm curious how the encoder balances compression quality in the face of its physical contraints: limited video buffer size along with rigid real-time encoding deadlines.

In order to use backward prediction in B-frames, the next I or P-frame must be encoded in advance. This requires the encoder to temporarily buffer unencoded video frame data for each consecutive sequence of B-frames, in addition to maintaining video buffers for two encoded I and/or P-frames. With the standard IBBPBB frame-sequence, the encoder must continuously juggle the video data from four consecutive frames at the same time. As bitrate is increased, the worst-case buffer size required for encoded I and P-frames will increase as well.

With the GH1, there were clearly cases where video buffer overflows (rather than SD card write-speed limitations) were the cause of fatal recording errors. I wonder if GH2 is also vulnerable to buffer overflows, and if it needs or can be patched to eliminate this pitfall?

On the GH1, I also spotted macroblock quality reduction in lower parts of certain frames. In addition to running out of bitrate in the middle of the frame, I suspect that running out of encoding time can also force the encoder to resort to shortchanging macroblock optimization.

@lpowell

I think the prediction process sometimes doesn't have time to try all possibilities, which is not optimal. I know, for example that it limits the number QP values it tries in I frames to five, and P and B frames are encoded with a single QP value. Obviously there isn't the CPU bandwidth to try more QP values. I assume there are other, more dynamic prediction compromises it makes as well.

I looked at the buffering in the GH2 and it looks like it assumes B frames for all modes (even the ones that don't use B frames) - this is good.

Your comment on the GH1 overflow - amen, I couldn't agree more.

Chris

@Lpowell

I think I just figured out where the Gh1 "rogue" frames came from. AVC codecs provide a couple of parameters intended for decoders - a bitrate, and a CPB (coded picture buffer) size. Some decoders use these to configure themselves, some (like StreamParser) don't. There is a bug in the GH2 codec where if the bitrate/1024 goes above 32767, the reported bitrate becomes this huge number. It happens because the code in the codec uses a signed extension instruction to convert to 32 bits instead of an unsigned one. Even with that fix, if the number goes over 65535, you still get a bad number. Some decoders (most, actually) don't rely on these parameters. Technically, however, you are supposed to, and streams with bad values there are not compliant. I think Elecard's StreamEye quite correctly does use these values and that results in the strange "rogue frame" interpretation.

Chris