Keyframe distance effects don't make sense

[rgames]

I create a lot of timelapse videos and one issue I run into quite often is blocky artifacts in clouds and skies.  One approach I've taken to try to deal with this is changing the keyframe distance which, if I understand it correctly, defines the distance between reference frames that are used for some kind of relative compression in the non-reference frames.  In theory, the best video quality occurs when keyframe distance is 1 so that every frame is compressed independently and not as a change to some other frame.  That much makes sense to me.

But my experiments show exactly the opposite - the larger the keyframe distance, the better the image quality.  I've linked some examples below.  These are all for an H.264 two-pass VBR encode between 140 and 160 Mbps.  I used the "High Unrestricted" profile as well as "Main 5.2" and don't see much difference.  I've tried both hardware and software encodes and they also look pretty much the same.  The 72 distance is the default and provides the best overall image quality.  10 is a little worse but probably about the same.  1 is horrible.  As far as I understand what keyframe distance is, that's exactly the opposite of what's supposed to happen.

So... what am I doing wrong?

Video for distance = 72: https://drive.google.com/file/d/1cmdECFXaDnde_kfiN8kbVwZ_EprWW1ZX/view?usp=sharing

Video for distance = 10: https://drive.google.com/file/d/1hs8LPHAjosRyrku75KqZtxC1C-6MNv41/view?usp=sharing

Video for distance = 1: https://drive.google.com/file/d/16-hURgVLN1kSZIdHUcKNruu8sFuLmrUL/view?usp=sharing

[MyerPj]

You can use the free MediaInfo program to get info on your clips. Get the program from the link below and using the 'Tree' view post a screenshot of your clip info: https://mediaarea.net/en/MediaInfo/Download

The 10 and 72 looked pretty much identical with MediaInfo in Tree view

FYI: I doubt you get anything better with 2 pass

[R Neil Haugen]

Banding and blocking artifacts are very common in H.264 media, especially so but not limited to 8 bit files. It's the manner of the pattern used for deciding how to compress. More so than the distance between iframes.

As to reduce the data in compressing the files, it looks at neighboring groups of pixels ... I guess can be 4, 6, 8 or so pixels in a group. 

If you have say a block of four that are 18/23/42, 17/23/45, 18/21/43, 19/22/44 ... it may decide to simply store all four pixels as 18/23/43. 

And now you have a block of four identical pixels, and IF you have a smooth gradation as with walls or skies, you have blocks ... groups ... of identical pixels visible as blocks.

H.265 is supposedly less prone to this, but not necessarily by a long ways.

[rgames]

Thanks for the replies but I'm not sure what to take away from this info.

[R Neil Haugen]

To understand what is happening, you need to know why it's happening.

The above explains why the banding and blocking are so prevalent in H.264 exports. And therefore, why the distance between iframes (what you referred to as keyframes) isn't actually the cause of the problem.

As further information, if you start with H.264/long-GOP media, and do much change of tonality (contrast) or saturation/color, then export, you will quite easily get the banding or blocking. Remove the color changes, they are lessened if not eliminated.

Because the tonal and color changes, applied to the original image with a small level of un-noticed blocking, causes the blocking to become very noticeable.

So you can have banding/artifacting caused by either tonal/color changes to the file prior to export, the export process itself, in the compression process, or ... both.

Colorists tend to hate H.264 media with a purple passion. Yep.

[Remote Index]

Hello rgames,

After a quick look, I concur with your assessment that keyframe distance 72 has a higher quality image than keyframe distance 1.

However, while this may seem counter-intuitive, it may make more sense if you understand how long GOP compression works.

Every frame that you refer to as a keyframe (or "referene frame") is fully stored in the file. All other frames are represented as simply "diffference information" - there is not a complete frame stored, only information about how to recreate the frame in terms of differences from the keyframes. Keyframes - being full frames - are a larger chunk of data; the other frames since they are represented only in reference to the key frames, are much smaller in terms of the data needed to store them. They're 'recreated' in playback by referencing the keyframes.

This scheme is how GOP codecs (like H264) acheive such incredibly high compression rates (and small file sizes), and why they are computationally demanding in playback.

To understand your examples, you have to consider both key frames and the bit rate.

Your first example, keyframe distance 72 means that in 3 seconds (72 frames of video at 24fps), there are only 2 full frames stored. Every other frame between these two is "difference information" (ie much less information). Your last example, keyframe distance 1 means that in 3 seconds (72 frames of video at 24fps), there are 72 full frames stored and no "diffference information" since all frames have been stored as full frames.

You may now understand that if you have the same bitrate for both (meaning the same amount of data per second, or the same file size for 3 seconds of video), the first file has much more data to alot per frame (for example, 166MB for 2 frames!) than the second file which has much less data per frame (same example, 166MB for 72 frames!). I'm ignoring here the "difference information" for simplicity's sake ... that does require some data to be alotted to it, but the data requirements are much smaller, and so I'm ignoring that to make the point and illustrate the principle. In this simplified calculation, the first example has 83MB per frame and the second less than 3MB per frame.

" In theory, the best video quality occurs when keyframe distance is 1 so that every frame is compressed independently and not as a change to some other frame."

This is true as far as it goes - it is true only if you increase the data rate so that each "reference frame" is alotted the same amount of data in your examples. As you decrease the keyframe distance, you need to increase the bit rate and video file size (otherwise as every frame becomes keyframe, it also gets a smaller data alotment). If you want comparable quality, 72 frames stored will be larger than 2 frames stored. The difference will not be as dramatic as my simplified calculation implies (I've ignored the "difference information" frames), but it will still be a difference.

Hope that helps.

R.