Personal View site logo
AVCHD: Encoder inner workings
  • This discussion was created from comments split from: GH2 Stalin samples topic.
  • 19 Replies sorted by
  • I think you are correct about the gradients. The lowest macroblock compression ratio used in the GH2 is 5:1, which is a lot. It's not directly related because transforms are manipulated in the frequency domain, but there is a loose relationship between compression ratio and gradation response. With eight bit data you loose more than two bits of information per data word when compressing 5:1 - that's a lot.

    Chris
  • @Mark_the_Harp
    I won't have my hands on a GH2 for another couple of weeks yet, so this is an informed guess.. I would say the banding would be reduced by raising the bitrate, but it may not be quite so simple to increase it. The camera maybe detecting low-detail or low-brightness areas and automatically lowering the bitrate.

    Motion artifacts aside I think the GOP rate is a balancing act.. technically on a non-real time encoder a higher GOP rate should result in 'better' compression and therefore more detail per Mbps, but it's almost certainly not that simple a relationship with the GH2 encoder.
  • Actually, the typical way variable bitrate AVCHD codecs work is that they establish limits on things like quantization levels, etc... If the best quality limit has been met for each macroblock in a frame the codec reduces bitrate instead of improving quality further. One reason for this is because there isn't enough CPU bandwidth to try all levels of quality. On quantization, for example, only 5 levels are tried for I frames and only 1 is tried on other frames on the GH2. The CPU simply doesn't have the time to try all 52 levels. So, what happens if the bitrate for a frame is used up before the frame end is reached, even though the lowest quality setting has been used for all macroblocks? The codec just bails and the lower part of the frame will look terrible. Actually, you get the same effect to a lesser extent if the codec has used too many high-quality values too soon and runs out of steam because of that. This is a one pass codec, so it relies on the quality of initial estimates. It usually works well, but sometimes not.

    Chris
  • @cbrandin - I've seen lower-frame blurring of AVCHD image details on the GH1 as well, particularly in testing shadow detail in dense foliage. I suspect this happens fairly often, as many outdoor scenes have bright blue skies in the upper frame and darker background details in the lower part of the frame.

    I'd also expect AVCHD's quantizer predictions to become riskier as GOP-length is increased. The encoder must attempt to select the optimal quantizer level out of 5 for macroblocks in each key frame, and hope that this will continue to work well in subsequent P and B-frames. With a short-GOP encoder, the penalty for quantizer mispredictions cannot persist over very many frames.
  • I haven't figured why yet, but the GH2 files only have one key frame (maybe some more way down the stream, I haven't looked) and it's the very first frame. I frames are not necessarily key frames, but I'm not sure what the difference is (maybe special metadata of some sort?). Maybe key frames contain custom tables of some sort that affect the entire stream. I'll have to do some more research on this. Any ideas?

    Chris
  • One thing I have noticed is that B and P frames are very limited in their capability to improve on the I frame they reference. In fact, I can't detect that they can improve the image at all.
  • By a key frame do you mean an I-frame that starts a closed GOP? I wouldn't be surprised if the entire AVCHD stream is open-GOP, as it's not really designed for editing.
  • Can you explain the difference between an open and closed GOP to me? What I mean by key frame is whatever StreamEye detects as a key frame - however they do that.
  • Can you tell if B-frames are able to selectively encode intra-compressed macroblocks? That is potentially one of their most significant quality advantages.
  • A closed GOP is self-contained; none of its B-frames is allowed to reference macroblocks found in frames outside of the GOP. This makes it possible to cut and paste on GOP boundaries without re-encoding any frames. Open-GOP encoding is used to make the bitrate more consistent. In particular, open-GOP encoding allows B-frames near the end of a GOP to reference macroblocks in the I-frame that starts the next GOP.
  • Thanks for the explanation. Doesn't that mean that in a closed GOP frame the last B frames are actually P frames? In any case, the GH2 streams are certainly open GOP. Are there any other implications of open GOP streams - like metadata that is propagated across I frames, for example?
  • Yes, I've seen intra encoded macroblocks in B frames.
  • Yes, much like P-frames, the trailing B-frames in a closed GOP can only reference macroblocks in previous frames. There are additional distinctions between P and B-frames, but the differences in how they're applied in the various AVC profiles is out of my depth.

    If P and B-frames cannot improve on I-frame quality, does that mean they're not allowed to exceed the size of I-frames? It was very common on the GH1 for P-frame size to exceed that of I-frames during panning.
  • Yes, I've seen that too, but those frames didn't look better to me most of the time. Maybe it's not absolute. It's just something I noticed.
  • Come to think of it, the only reason P frames would be bigger is because deltas and motion vectors actually proved to be anathema, otherwise the frame could have been coded with intra macroblocks and be the same size.
  • Right, the large P-frames didn't look any better. I figured the encoder got stuck compensating as best it could for poor motion vectors that needed a lot of correction. However, the excessive P-frame size would starve bitrate from subsequent I-frames, exacerbating the problem.
  • Thanks Chris and LPowell for your efforts and expertise you guys bring in, really appreciate it!
  • Moved AVCHD encoder talks to this topic.
  • @Vitaliy

    Maybe wrong topic, but using new 64Mb/s 1080 24P 3 GOP settings will write perfectly to card but will stop each time at 4GB limit. Is this because of the settings or will 24P clips just not span? Only settings I changed are:

    Video Bitrate 24H=65000000
    Video Bitrate 24L=35000000
    1080i50 and 1080p24 GOP Size=3
    Video buffer 24p=0x3600000
    1080p24 High Top Setting=42418
    1080p24 High Bottom Setting=29692
    1080p24 Low Top Setting=31178
    1080p24 Low Bottom Setting=21824