keyframe interval recommended for h264 video at 50 fps

[codemaster]

I'm using x264 to compress a video that has 50 fps. I don't know what values to use for the x264 parameters "--keyint" and "--min-keyint".

Which of the following two options do you recommend?
a). "--keyint 500" and "--min-keyint 50";
b). "--keyint 250" and "--min-keyint 25".

And optionally, explain why you recommended the option that you recommended.

[KarMa]

I usually see (fps * 10) = Max GOP size as a good all around setting. So for 50fps, you would do a keyint of 500. It's really just a matter of how long of a GOP you want, with longer GOPs being more efficient but harder to seek in. Smaller GOPs are less efficient but easier to seek in. It's really up to you.

[jagabo]

Depends on your goal. Some devices have playback limitations. You get vastly diminishing returns as keyint increases. The difference between 250 and 500 will probably be less than 1 percent. Maybe as little as 1/10 percent. Just run both and see for yourself.

[hello_hello]

I've generally used keyint 500 because I use MeGUI and it sets keyint automatically to 10x frame rate and I forget about it.

Mostly it doesn't matter much as x264 does a good job of putting a keyframe on the first frame of each scene, so every time the video switches from one camera shot to another the keyint "resets" (500 is just the maximum), and mostly the distance between keyframes would be less than 10 seconds. Hence jagabo is no doubt correct about a very large keyint not making a huge difference to compression.

I've noticed when my old Nvidia 8600GT is doing the decoding there's an occasional "glitch" when keynt=500 is used, as though a frame has been repeated. It took a while for the penny to drop and for me to realise it was only happening during longer scenes, so the video card's decoding doesn't like a keyint of 500 (the "glitch happens at about 8 seconds into a GOP, from memory), but I haven't noticed any other playback issues. The TV's built in media player seems fine with keyint 500 (at least for standard definition) as is the Bluray player playing video via USB, and CPU decoding is fine, so it's just a limitation of my 8-9yo video card's decoding. Nothing serious enough playback-wise to force me to remember to set keyint myself when encoding with MeGUI.

The way I understand it, the minimum keyint setting is to prevent the encoder creating a succession of keyframes when there's large changes from one frame to the next.... when there's a strobing effect or that sort of thing. As far as I know it can still use I-frames, but they're not IDE frames or keyframes. There's probably no reason why you couldn't use keyint 250 and min-keyint 50 if you wanted to.... or some other combination.
https://en.wikibooks.org/wiki/MeGUI/x264_Settings#keyint

[jagabo]

Larger GOPs also make it harder to seek during playback. So random seeking, fast-forward, reverse play, are all more problematic. One example: a lot of players only show keyframes when fast-forwarding (at higher speeds). Seeing a frame from each second of the video rather every 10 seconds of the video makes it much easier to see what's going on.

I ran some quick tests. I didn't have a 50 fps source hand but here's 10000 frames of a 23.976 fps DVD source CRF encoded with different keyint sizes:

keyint	bitrate
---------------
5       2153
10      1721
20      1467
50      1313
125     1257
250     1248
500     1242
1000    1241

and graphically:


[Attachment 40800 - Click to enlarge]

A 50 fps source would probably shift the graph a little to the right. And the exact values will depend a bit on the particular video. But the general trend is obvious.

[ron spencer]

The easiest thing to do is to use the Bluray Standard...set keyint=frame rate. So in your case set keyint=50 and be done with it. X264 will sort out min keyint itself. Note keyint can only be integer, so for 23.967 use 24. I use this for all my encodes...never an issue, easy to remember and it will play on anything (assuming your other parameters are ok).

[hello_hello]

jagabo,
It'd be interesting to see the same test again, only with ConvertFPS(50,1) or something similar added to the script.
It's just that at 24fps a keyint of 500 would rarely be reached due to the placement of keyframes on scene changes, whereas if you double the frame rate, it's more likely to, hence using keyint 500 for 50fps. Admittedly looking at your tests it doesn't appear as though it'd make a huge difference, but it might also depend if those 10000 frames were long static scenes or fast changing shots of action footage.

ron spencer,
Admittedly it's all personal preference, but keyint 24 does put a dint in compressibility compared to keyint 240. I remembered it being in the 5% to 10% range, but it's more like 15% for jagabo's test above.
While keyint24 is the official Bluray spec, even Bluray players capable of playing video via USB don't require it. The default of 250 is fine. High Profile 4.1 is generally fine.

Admittedly I use a PC for playback so the number of times I've had to "fast forward" video in the last ten years wouldn't be far above zero. I click on the navigation bar with a mouse so I have a slightly different perspective, although I've not had any complaints from the "fast forwarders" in the house.

[ron spencer]

@hello_hello

To be honest, I just use keyint=fps as it is easier to remember

I realize there is a compressibility hit, but I'm not worried about file size too much. Enjoy!

[jagabo]

It'd be interesting to see the same test again, only with ConvertFPS(50,1) or something similar added to the script.
It's just that at 24fps a keyint of 500 would rarely be reached due to the placement of keyframes on scene changes, whereas if you double the frame rate, it's more likely to, hence using keyint 500 for 50fps

I used mvtools to double the frame rate to 47.952 fps and encoded with keyint 250 and 500. Added them to the chart:

keyint	bitrate
---------------
5       2153
10      1721
20      1467
50      1313
125     1257
250     1248    1361
500     1242    1352
1000    1241

Very slight relative difference. About 0.5 percent improvement at 24 fps vs. 0.7 percent at 48 fps.

[hello_hello]

Now you made me try it.
PAL DVD, old BBC sitcom, 30,000 frames (10 min). The opening sequence is quite busy, while the rest is more static.
De-interlaced to 50fps with Yadif(mode=1).
Cropped and resized to 704x528.
Default x264 settings aside from CRF18.

keyint  bitrate
25     2768
50     2561
125    2392
250    2343
500    2325
1000   2320

Same as above, only using the x264 slower preset and CRF18.

keyint  bitrate
25     2716
50     2510
125    2338
250    2285
500    2265
1000   2261

That's altered my view of the world a little. Before I forget, I'll change my MeGUI x264 encoder presets to a fixed keyint of 250 instead of 10x the frame rate, which is the x264 default anyway......

[ron spencer]

Now you made me try it.
PAL DVD, old BBC sitcom, 30,000 frames (10 min). The opening sequence is quite busy, while the rest is more static.
De-interlaced to 50fps with Yadif(mode=1).
Cropped and resized to 704x528.
Default x264 settings aside from CRF18.

keyint  bitrate
25     2768
50     2561
125    2392
250    2343
500    2325
1000   2320

Same as above, only using the x264 slower preset and CRF18.

keyint  bitrate
25     2716
50     2510
125    2338
250    2285
500    2265
1000   2261

That's altered my view of the world a little. Before I forget, I'll change my MeGUI x264 encoder presets to a fixed keyint of 250 instead of 10x the frame rate, which is the x264 default anyway......

What is advantage of higher keyint. 250 vs 50?

[hello_hello]

What is advantage of higher keyint. 250 vs 50?

Assuming the same CRF value produces the same quality each time, then according to the bitrates keyint 250 offers about 10% more compression than keyint 50. It's not a huge amount for a single, small file, but it'd add up. I guess it depends how fussed you are about file size. I'm not overly fussed myself as I'd give quality a reasonable amount of preference over file size, but keyint 250 at least helps claw back a little hard drive space.

As to whether they are the same quality..... at CRF18 I can't really tell. If I open the keyint 250 sample and find a keyframe that's 5 seconds away from the previous keyframe (50fps in this case), then step back a couple of frames, I assume I'd be at the lowest quality point, given I'm near the end of a maximum sized gop. If I compare that frame to the same frame in the keyint 50 sample, and compare them both to the Avisynth output of the same frame, I can see there's differences in the way they're encoded, so they both vary from the source, but I can't really say for sure one frame is encoded more accurately than the other, although I'm inclined to give the keyint 250 sample a slight edge.

If I compare a keyframe in the keyint 50 sample with the same frame in the keyint 250 sample, but where for the keyint 250 sample it's not a keyframe, there's no doubt the frame in the keyint 50 sample is encoded more accurately, so that's where the 10% extra bits are spent.

None of that is stuff you're likely to see at CRF18 though. You'd have to pause the samples and check identical frames, but one advantage of long gops is there's less potential for noticeable "keyframe pumping" at low bitrates, because the keyframes usually only land on the first frame of a scene change when keyint is 10x the frame rate, so if the quality suddenly improves it's harder to tell. If there's several keyframes throughout a long, fairly static scene, at low bitrates there's more potential for the quality to noticeably increase when a keyframe is reached, then steadily drop until the next one. You've probably seen stupidly low bitrate encodes like that where the first frame looks okay, then the following frames become blocky crap really quickly, then at the next keyframe it's okay again for a frame or two.... that's one reason open-gop is recommended for Bluray encoding.

Pros and cons either way. For fun, later on I might try again, but this time using 2 pass encoding to compare them at the same bitrate. I'll probably do it using a much lower bitrate than before so it should be easy enough to tell if a larger gop does translate to an increase in quality at the same bitrate.

PS I've only properly compared the encodes using the x264 medium speed preset so far, but a quick looks at the slower preset encodes indicates the same sort of thing applies.

[ron spencer]

@hello_hello Thanks for your response. Good info to know!!

[ron spencer]

Lower keyint values are more easily seekable right?

[hello_hello]

Lower keyint values are more easily seekable right?

In theory they would be, although it'd depend a little on your definition of "seekable".

I have "fast seeking" enabled for MPC-HC, which simply means it'll seek to the nearest keyframe when using the navigation bar, so if I seek to a random point in a keyint 250 source it's likely to end up a little further away from the exact location I specified than for keyint 50, but it's instant either way. With fast seeking disabled it navigates directly to the specified location, but if it's not a keyframe it has to decode any other required frames in the gop too, which can take a few seconds for 1080p. I'd imagine for keyint 50 there'd be less frames to decode (on average).

Then again, for keyint at 10x the frame rate, seeking with the navigation bar usually lands you on the first frame of a scene with "fast seek" enabled, and by default for MPC-HC, Shift+Left Arrow and Shift+Right Arrow navigate back and forth between keyframes, so when keyframes are only on the first frame of a scene (most of the time) it's an easy way to effectively jump from one scene to the next. I thought about that when comparing the samples earlier because for keyint 50 I was skipping in one second intervals most of the time and it seemed odd because I'm set in my ways.

Generally the only time I'm wanting to navigate to a non-keyframe is when I'm comparing encodes and for that I use the MPC-HC Navigate/GoTo menu (Ctrl+G) as it ignores the fast seek option and takes you to the specified frame number.

I guess it all depends on your player and how you watch video etc. Whenever I walk into the room and my mother's using the TVs media player to "fast forward" through video as though it's a VCR, I remind her how to use the remote to jump to a specific time instead. She sometimes remembers to do it now. It's not as easy as clicking on a navigation bar with a mouse, but it cuts down on the amount of fast forwarding required. I've no idea if it navigates that way using a "fast seek" type option as I've not thought about it until now. I might test it later, just out of curiosity. She's never complained about the fast forwarding though, and most of the video I put on her hard drive would be encoded with keyint 240 or keyint 250. I can't say from experience what difference a smaller keyint might make when fast forwarding.

[Takashi]

I usually see (fps * 10) = Max GOP size as a good all around setting. So for 50fps, you would do a keyint of 500. It's really just a matter of how long of a GOP you want, with longer GOPs being more efficient but harder to seek in. Smaller GOPs are less efficient but easier to seek in. It's really up to you.

Hi, what values would you use to get the best video quality without importing the compression?

PAL
GOP calculation: FPS based or Fixed?
keyint?
min-keyint?

NTSC
GOP calculation: FPS based or Fixed?
keyint?
min-keyint?

And now what values would you use to get the best compression?

PAL
GOP calculation: FPS based or Fixed?
keyint?
min-keyint?

NTSC
GOP calculation: FPS based or Fixed?
keyint?
min-keyint?