What a keyframe interval actually does
A keyframe is a complete picture; every other frame only describes what changed. A viewer cannot start watching until one arrives, so a two-second interval means up to two seconds of blank player before your stream appears for them.
Keyframe interval is one of those settings that looks like it belongs to the encoder and actually belongs to your audience. It does not visibly change quality at sensible values. What it changes is how long a newcomer waits, and how much of a broken stream they see before it repairs itself.
What the encoder is doing
Video compression works by not sending the same thing twice. A keyframe is a complete, self-contained picture. Every frame after it describes only the difference from what came before, which is why an hour of a static lectern shot costs so much less than an hour of a football match.
The run from one keyframe to the next is called a group of pictures, and its length is what you are setting when you set a keyframe interval. Set it in seconds rather than frames and it stays correct when you change frame rate.
Why a new viewer waits
A player joining a live stream cannot do anything with difference frames, because it has no picture to apply them to. It has to wait for the next complete one. With a two-second interval, somebody clicking your link waits somewhere between nothing and two seconds before anything appears.
This is the entire practical consequence of the setting. It is also why very long intervals feel broken to an audience even though every technical measurement looks fine: a ten-second group of pictures means a ten-second blank player for anybody arriving at the wrong moment, and most of them will leave before it resolves.
It also governs how fast a stream repairs itself
When packets are lost, the difference frames that follow describe changes to a picture the player no longer has. The result is the smearing and blocking everybody recognises, and it persists until the next complete picture arrives to reset the state.
So the interval sets your worst-case recovery time as well as your worst-case join time. A shorter interval repairs faster. Two seconds is the conventional value for live streaming because it is short enough that neither number is painful and long enough that the extra complete pictures do not cost meaningful bitrate.
Where the platforms come in
Every large platform re-segments your stream for delivery, and it prefers to cut segments on keyframes. A stream whose interval does not divide cleanly into the platform’s segment length forces it to either wait or re-encode, both of which add delay between you and your audience.
Two seconds divides cleanly into essentially every platform’s segmenting, which is the other reason it is the default answer. Unless you have a specific reason, this is not a setting that rewards tinkering.
Building against the API rather than running a show? Setting the output format (developer docs) covers the same ground in implementation detail.
Put it to work on a real show
A daily show lives on people arriving mid-broadcast from a link in a post, which is exactly the case join time decides.
If you are weighing an appliance workflow against a browser one, the settings it hides from you are worth understanding first.
Related guides
For 1080p30, about 6 Mbps. For 1080p60, about 9. For 720p30, about 3, and 720p60, about 4.5. Frame rate drives the number far harder than resolution does, and your upload has to sustain it, not peak at it.
Choose 60 when the subject moves: sport, gameplay, a stage, a fitness class. Choose 30 for talking heads, slides and lecterns. Sixty costs roughly half again as much bitrate and buys nothing on a static shot.