Keyframes when encoding in x264

[alexVS]

I'm encoding mpeg2 (25 FPS interlaced) captured from TV into MP4 (x264)
Since it's a sport competition, I'm encoding it at 50 FPS to preserve smothness.

Avisinth script is something like:
mpeg2source
separatefields
bob
crop
resize

The question is: what keyframe interval should I use when encoding at 50 FPS? The standart for 25 FPS is every 300 frames. Shoud I increase it, decrease it or leave it as is?

[check]

A larger keyframe interval has two effects:
1. Seeking can be slower. To seek, the encoder has to go back the previous IDR (key) frame and decode every frame up to the one requested. If the keyframe is further away, this process takes longer.
2. Better compression. A forced I frame is a less efficient compression of the video than the standard P/B frame that would normally be used at that point. Setting a higher max keyframe interval reduces the incidence of this compression loss.

In practice, the compression loss from forcing I frames every 250 frames instead of every 1000 is pretty small. The loss in efficiency diminishes pretty quickly after a few hundred KFs. It might be interesting for someone to run some tests though.

[Manao]

The average intra frame is 3 to 5 times bigger than a P frame. So Forcing an intra every 300 frames artificially increases the bitrate by 3/300 ~ 1%, while one every 1000 frames increases it by 3/1000 ~ 0.3%.

And that is supposing that there's only one huge scene, while actually the average scene duration is less than 10 seconds. So in real life, the efficiency loss is minimal.

[alexVS]

A bit difficult for me to understand.

Before I encoded my video as 25 FPS with bitrate ~1300 Kb/s

Now I encode as 50p FPS to preserve smothness. As far as I understand, I should increase bitrate up to ~1800-2000 Kb/s to get the same picture quality.

The default keyframe interval is 250 frames.
Should I increase or decrease this value to get better picture quality when encoding as 50p FPS?

[akupenguin]

The average scene length (measured in frames) has doubled, so in order to keep the bit cost of keyframes at a similar level, keyint would stay at 10 seconds i.e. increase to 500 frames.
Otoh, the cpu cost of seeking to a given point depends on the number of frames you have to decode, not the amount of time they represent. So to keep the worst case seeking cost constant, keyint would stay at 250 frames.
The balance between those means that the optimal keyint scales sub-linearly with fps.

However, whether you use 250 or 500 or something in between, you probably won't notice the difference. So just pick a number.

[Manao]

Whatever the framerate, the bigger the keyframe interval, the better the quality, the harder it is to seek in the file.

If you don't care at all about seeking, use as high a value as you want ( I wouldn't go over 1000, because it's really useless to go over that, but that's a personnal opinion ).

[alexVS]

OK. Now I understand.

Earlier I thought, the more keyframes I have, the better quality I have. Because keyframes (I frames) contain full information about picture. And other (P,B) frames - only changes in the picture. The perfect video contains only I frames (like uncompressed video). That way I thought.

[check]

A p or b frame could theoretically contain a perfect representation of the image as well, if you use a very low quantizer (or lossless) you will see this to be the case. What is not the case is an I frame being 'better' than P or B frames. In terms of compression, it's far worse, P and B frames are much more efficient. If you increase the number of I frames, you reduce the overall efficiency of the video, which decreases quality.

[akupenguin]

I-frames aren't even as good quality as P/B-frames of the same QP. Because if you put an I-frame anywhere other than a scenecut, its quantization error will be independent of the previous frame, which leads to temporal fluctuations that weren't in the source, which is ugly.