Low latency live streaming: get your viewers closer to the moment

Why a live stream runs behind

A live stream runs behind because every stage between lens and screen holds on to the picture for a moment, and those moments add up. Your encoder compresses a few frames before it sends anything. The link to the server buffers to survive a bad patch. The server cuts the video into files for players to fetch. Then the player keeps a cushion of video so a hiccup on the viewer's Wi-Fi does not freeze the picture.

That last cushion is usually the biggest. In regular HLS, the format nearly every phone and browser plays, the specification tells players not to start closer to the live end of the playlist than the server's HOLD-BACK value, which must be at least three times the segment target duration and is taken as exactly three when the server gives none. With segments of a few seconds each, that alone puts viewers well back from live before anything else is counted.

So there is no single switch. You shorten the first mile, you choose a delivery format that is allowed to play closer to the edge, and you set your encoder so the server can cut the stream finely.

How close does your show need to be?

It depends on whether your viewers act on what they see. Somebody watching a concert does not mind being a little behind; a bidder in a live auction or a guest asking a question in real time does. Pick the format by the job, not by the lowest number you can find.

In our own tests, published on the live streaming player and Cue pages, low-latency HLS ran about six seconds behind live; WebRTC plays in under a second.

What Low-Latency HLS changes

Low-Latency HLS keeps the same playlists and segments players already understand and adds a faster lane at the live edge. Apple describes it as bringing delay over public networks down into the range of ordinary television broadcasts, while keeping the scale of HLS. These are the main pieces, as Apple's guide and the HLS 2nd Edition specification describe them:

• Partial segments. Each segment is also published as small parts, announced with the EXT-X-PART tag, so a player can fetch the newest fraction of a second instead of waiting for a whole segment to finish.
• Blocking playlist reload. The player asks for a playlist that does not exist yet, using _HLS_msn and _HLS_part in the request, and the server holds the answer until that part is ready. No more polling on a timer.
• Preload hints. An EXT-X-PRELOAD-HINT tag names the next part before it exists, so the player can request it early and receive it the moment it is written.
• Rendition reports. Each playlist carries a short report on the other quality levels, so a player can switch quality without extra round trips.

The server also tells players how far back to sit, with PART-HOLD-BACK. The spec says it must be at least twice the part target duration and should be at least three times it. A player that finds the server missing any of these pieces falls back to regular-latency playback, so a low-latency stream still plays everywhere, just not always as close to live.

The trade-off is written into the spec itself: a shorter target duration cuts delay but leaves less buffer and makes stalls more likely, and a longer hold-back reduces stalls but adds delay. Low latency is a choice you make for each show, and it always trades away some buffer.

The first mile: getting your feed in quickly

Before viewers can be close to live, your channel has to be. A Primcast channel takes three ways in, and the dashboard prints the settings for each one ready to paste.

• WHIP (WebRTC), on all plans. Publish from OBS 30 or straight from a web page, with around half a second of delay into your channel. WHIP is the IETF's standard way to push WebRTC into a streaming service, and it goes directly to your channel's server. Handy for a guest who only has a laptop.
• SRT, from Starter. Built for lines you cannot trust, such as a shared venue uplink or a phone hotspot: it recovers lost packets so the picture holds, and it enters at the nearest of our 5 cities. Each channel gets its own port and passphrase.
• RTMP, on all plans. The one every encoder speaks, also entering at the nearest city. It is the safe default when the encoder offers nothing else.

With SRT, the delay is a setting you can see. The SRT library's documentation describes its latency value as the minimum buffering the receiver applies before handing packets on, used to absorb jitter and leave time to resend lost packets. In live mode it defaults to 120 ms, and the two ends settle on the larger of the values each side asks for. On a long or lossy path a bigger value gives retransmissions room to arrive; on a clean, short one you can keep it small.

Setting up a low-delay channel, step by step

1. Choose a plan with low latency on it. The video streaming plans list Low-latency HLS and DASH on Starter, Pro and Platinum; the Free plan plays regular HLS and DASH.
2. Set your encoder's keyframe interval short. The low-latency profile in the HLS spec recommends a group of pictures between one and two seconds, and every full segment has to contain at least one frame a player can start from.
3. Connect over WHIP if you publish from OBS 30 or a browser, or over SRT if the camera is on a venue line or a mobile link. Copy the address, port and passphrase from your channel's dashboard rather than typing them.
4. Paste the ready embed code from your control panel into your page. The player picks the playback route for each browser (hls.js on Chrome, Edge and Firefox, Apple's built-in HLS on Safari), so you embed one thing.
5. Measure before the real show. Put a running clock in front of the camera, open the stream on a phone on mobile data and on a laptop, and compare. Your own number on your own network beats any figure on a web page.
6. Keep the Live tab open during the test. It shows the rate your encoder is sending, how long it has been on air and who is watching, which helps you tell a weak uplink from a weak viewer connection.

When every viewer needs to be under a second

WebRTC is the format for that. It was built for real-time calls, so the player is not waiting for files to be written and fetched the way HLS does. With Cue on a dedicated server of your own, the Cue Player can play WebRTC under a second behind live, and where a viewer's network will not allow it, the player quietly switches to regular HLS instead of showing an error. Hosted video channels play Low-Latency HLS and DASH from Starter up.

If sub-second playback is the whole point of your show, such as a live auction run on your own website, look at Cue, our streaming engine, on a dedicated server of your own. It takes WebRTC in through WHIP and plays WebRTC out to viewers, under a second behind live, alongside Low-Latency HLS and DASH for everyone else, with DVR and quality versions for slow connections on the same machine. Not sure which route fits your show? Ask us in the chat.

Paid shows: when FairPlay or Widevine DRM is switched on for a stream, it plays over standard HLS and DASH, and WebRTC and low-latency HLS stay off for that stream. Decide which matters more for each event.

Where low latency is the wrong goal

Chasing the smallest delay costs you buffer, and buffer is what keeps a picture smooth on a crowded train. If your audience watches rather than takes part, regular HLS with a comfortable cushion is the kinder choice, and it is what most broadcasts use.

Big one-off nights are their own case. For a ticketed match or a conference with a crowd, see live event streaming on our CDN, where venues send SRT and you size the days, hours and viewers before the night. And for how the 5-city network carries your stream to each viewer from the city closest to them, the video CDN page walks through it.

Questions people ask

What counts as low latency for a live stream?

There is no single official number. In practice it means a delay short enough that viewers can react to the show while it still matters. In our own tests, low-latency HLS ran about six seconds behind live; WebRTC, on Cue, plays under a second behind. Regular HLS sits further back by design.

Should I pick Low-Latency HLS or WebRTC?

Pick WebRTC, which plays on Cue on your own server, when the audience talks back or acts on what it sees, as in auctions and live Q&A. Pick Low-Latency HLS when you want most of the gain while keeping the reach and caching of ordinary HLS, as for sports. On Cue every input reaches every output at the same time, so one show can give WebRTC to the people taking part and HLS to everyone else.

Does SRT itself make my stream low latency?

SRT shortens and steadies the trip from your encoder to the server, which is only the first part of the delay. Its latency setting, 120 ms by default in live mode, is the buffer the receiver keeps to repair lost packets. Viewers still see whatever delay the playback format adds afterwards.

Which Primcast plan do I need for low-latency playback?

Starter, Pro or Platinum. All three list Low-latency HLS and DASH, and they also take SRT. The Free plan takes RTMP and WHIP and plays regular HLS and DASH. You can move up from your dashboard later without starting over.

Why is my stream still behind after I switched to low latency?

Check the stages one by one. A long keyframe interval, a large SRT latency value, an encoder buffer or a player that has fallen back to regular playback can each add seconds. Test with a clock in shot and change one thing at a time.