What latency means here
In live streaming, latency is the gap between something happening in front of the camera and the same moment appearing on a viewer’s screen. It is sometimes called glass-to-glass delay, because it spans the camera lens to the viewer’s display.
It is different from startup time, which is how long a viewer waits for playback to begin, and from buffering, where playback pauses. A stream can start quickly and never stall while still running well behind real time. The related pause problem is covered in buffering causes.
Typical ranges
Exact figures depend on the setup, so only rough categories are safe to give:
- Traditional segment-based streaming, as commonly used for large audiences, often runs tens of seconds behind real life.
- Tuned or low-latency versions of the same technology can often get to a few seconds.
- Real-time communication systems such as video calls aim for well under a second, using different technology.
These are general descriptions rather than guarantees. Individual services and events vary a lot.
Where the delay accumulates
Latency is not caused by one thing. It is the sum of many stages in the streaming pipeline.
Capture and encoding. The encoder needs to collect frames before it can compress them efficiently, and some compression settings look ahead several frames. Better compression often means more waiting. Whether it runs through hardware encoding or software also affects processing time.
Contribution to the platform. The encoder sends the stream to the service’s ingest servers over the internet. A poor uplink can add delay or force the encoder to hold data back.
Transcoding and packaging. The service typically creates several versions for different connections, then cuts them into segments. A segment generally has to be completed before it can be published, so segment length sets a floor on delay. If segments are several seconds long, that alone can mean several seconds of lag, and players usually need to hold more than one.
Delivery. Content delivery networks cache segments close to viewers. Time spent in these layers is usually modest compared with the others, but congested or distant paths can add to it.
Player buffer. To avoid stalls, players commonly wait until several segments are downloaded before starting. This is often the largest contributor. A larger buffer is safer against network dips but means the viewer sits further behind live.
Why services accept some delay
Delay buys stability. A deeper buffer and longer segments make streams more resilient to uneven connections, produce better compression and allow broad use of ordinary web servers and caches. For one-way viewing, such as a lecture or concert watched by a large audience, a gap of several seconds usually does not matter, and reliability is the better priority.
It matters more where timing is shared or interactive: live sports where viewers see social media updates first, auctions, betting-adjacent activities, quizzes, live shopping or chats with a presenter. In those cases lag can harm the experience or change fairness. Live events and sports coverage are where these concerns come up most, and event broadcasts are an area where services weigh them against cost.
How low-latency modes work
Reducing delay means shrinking the pieces that cause it, and each step has a cost.
- Shorter segments. Cutting the video into shorter pieces lets it be published sooner. The downside is more requests, more overhead and slightly less efficient compression.
- Partial segments and chunked transfer. Low-latency variants of HLS and DASH let a segment be delivered in smaller parts while it is still being produced, so the player can begin downloading before the segment is complete. The protocols themselves are compared in HLS and DASH, and a shared segment format often underlies both.
- Smaller player buffers. The player holds less video in reserve, so it stays closer to live but has less protection against network dips.
- Faster encoder settings. Choosing settings with less look-ahead lowers encoding delay at the expense of compression efficiency.
- Different transport. For the lowest delay, technologies like WebRTC calls send media over connections designed for real time. They can reach very small delays but are generally harder and more expensive to scale to very large audiences.
Together these choices form a spectrum. Lower latency means less slack, so a given network hiccup is more likely to produce a stall or a visible drop in quality, and adaptive bitrate has less time to react.
Practical considerations for streamers
Someone setting up a stream usually has only some of these levers. Many platforms offer a latency option such as normal or low, sometimes with notes that low mode may reduce quality or compatibility. The streamer’s own upload connection and encoder settings also matter, especially for a stable streaming setup.
If interaction with viewers matters, a lower mode is worth testing before an important broadcast. If the priority is picture quality or reaching viewers on poor connections, the default is often a more sensible choice. Either way, it helps to remember that every viewer has a different delay, since each player’s buffer and connection differ. Two people watching the same stream in the same house can be a few seconds apart.
An honest summary
There is no setting that removes latency without cost. The useful way to think about it is as a budget spread across stages, with reliability, quality, cost and scale all competing for the same room. Low-latency streaming is steadily improving, but the underlying trade-offs remain.