Bitrate, Keyframes and Latency: Streaming Terms Explained Plainly

When a streaming job goes wrong, the cause is rarely dramatic. More often someone nodded at a setting they did not quite understand, and it only showed itself once the audience was watching. I would rather every client could read the encoder page with us, so this note takes three terms we use constantly and says what they mean without the jargon.

The terms are bitrate, keyframe interval and latency. Between them they decide how sharp the picture looks, how well it survives a weak connection, and how far behind the room the viewer is. None of them is difficult once the idea is clear, and each one involves a trade-off rather than a right answer.

In our streaming productions the encoder sits between the control room and the audience, turning the finished programme into a stream small enough to travel over ordinary home connections. Everything below is about the choices made at that step, which is why it deserves a plain explanation before rehearsal rather than a rushed one during it.

• Bitrate: how much data each second of picture is allowed
• Keyframe interval: how often the stream can be joined cleanly
• Latency: the delay between the room and the viewer

Bitrate is the amount of data the encoder spends on every second of the programme, usually quoted in megabits per second. Think of it as a budget. A higher figure leaves room for fine detail and fast movement; a lower one forces the encoder to simplify, and the picture turns soft or blocky exactly when something busy happens on stage.

The temptation is to set it as high as possible. That helps only if the viewer can receive it. A stream that asks for more than a phone on a patchy connection can deliver will stall and buffer, which looks far worse than a slightly softer picture that plays smoothly from start to finish.

So we set the bitrate by looking at the audience as much as the picture. A talking-head conference needs very little. A concert with strobing lights and quick cuts needs a good deal more. We agree the figure with you in planning, test it during rehearsal on the same kind of connection your viewers will use, and leave a margin rather than running at the limit.

A video stream does not send a complete picture every frame. Most frames only describe what has changed since the last one. A keyframe is the exception: a full picture that a player can start from. Without one, a viewer who arrives mid-show would see nothing sensible until the next keyframe turned up.

The keyframe interval is simply the gap between them, normally a couple of seconds. A shorter gap lets people join quickly and recover faster after a hiccup, but each keyframe is expensive in data, so it costs some picture quality at the same bitrate. A longer gap does the opposite.

Streaming platforms often state the interval they expect, and a mismatch is a common reason for a stream that starts late or never appears for new arrivals. We check this setting against the destination early, long before the doors open, because it is one of those quiet details that costs nothing to fix on Tuesday and a great deal on Saturday night.

• Shorter interval: faster joining, slightly heavier stream
• Longer interval: lighter stream, slower to join

Latency is the delay between something happening in the venue and a viewer seeing it. Every step adds a little: the encoder, the network, the platform that splits the stream into pieces, and the player that holds a few seconds in reserve so playback does not stutter. Ten to thirty seconds is not unusual on a standard setup.

For a recorded-feel programme such as a lecture or a showcase, that delay is harmless. It becomes a problem when the audience interacts, for instance sending questions that the host answers live, or when viewers follow a second source such as the radio and notice the mismatch.

Reducing latency is possible, but it is bought with resilience. Smaller buffers mean less room to absorb a dip in the connection. We ask what the audience will actually do with the stream, and choose the lowest delay that the event genuinely needs rather than the lowest the equipment can reach, which keeps the broadcast steadier.

These values are not independent dials. Raise the bitrate and viewers on weaker connections struggle. Shorten the keyframe gap and you spend data that could have gone to detail. Cut latency and you remove the cushion that hides small network wobbles. Each improvement is paid for somewhere else.

That is why a single preset copied from another job rarely suits a new one. A seated panel, an outdoor stage and a product launch each deserve a different balance, and the right balance depends on the venue's upstream connection, the platform receiving the feed and the people watching it.

We usually start from a conservative profile, run it through rehearsal while watching the monitoring, and adjust only what the evidence shows. Having a backup path ready, such as a second encoder or a lower-quality fallback stream, means a surprise on the day becomes a switch rather than a silence, and the audience never needs to know anything happened.

• Start conservative, then tune from rehearsal evidence
• Keep a fallback stream ready on the day

You do not need to master the numbers, but a few questions will tell you whether they have been thought through. Ask what bitrate has been chosen and why, whether it was tested on a connection like your audience's, and what the keyframe interval is set to for the platform you are using.

Ask, too, what delay to expect and whether that suits any live interaction you plan. If the answer is a confident, specific one, the setup has been considered. If it is a shrug and a default, press gently, because defaults suit nobody in particular.

Finally, ask who watches the stream while it is running. Monitoring a live feed from the viewer's side, not only from the control room, is how problems are caught while they are still small. On our shows that is a named person with a headset, checking the picture the audience receives rather than the one we send.