Latency in a live stream is never one number you can fix at one point in the chain. It's additive: encode adds some, transport adds some, packaging adds some, and the last mile adds whatever's left over. Chase a fix at a single stage and you'll shave milliseconds off a problem that's actually measured in seconds. The chain has to be treated as a whole, especially for live events, sports, esports, concerts, where a five-second delay is the difference between a viewer's feed and their neighbor's phone notification.

Where It Actually Comes From

Encode-side latency comes mostly from GOP structure and buffering ahead of the encoder, longer GOPs compress better but hold more frames before they can be sent. Transport-side latency depends on the protocol: RTMP and HLS pull were built for reliability over speed, and it shows. Packaging-side latency comes from segment duration in HLS/DASH, a standard six-second segment means the player is never less than several seconds behind live by design, regardless of how fast everything upstream ran. And last-mile latency is whatever the CDN and the viewer's own connection add on top of all of it.

None of these stages is optional, but each one has a lower-latency alternative if the workflow is built for it.

Protocol Choice Does Most of the Work

SRT was built specifically to solve the transport-latency problem: rather than requesting retransmission of every dropped packet the way TCP does, it corrects for packet loss and jitter within a fixed, tunable latency window, so a lossy network degrades gracefully instead of triggering a retransmission storm that stacks delay on top of delay. That's the mechanism DOZER SRT is built around, hardware-accelerated packet correction on both ends of a contribution or distribution link, which is what makes SRT viable over public internet paths that would otherwise force a choice between reliability and speed.

On the decode side, D-Streamer takes SRT in and outputs SDI in real time, so the protocol advantage on the transport leg doesn't get undone by a decoder that reintroduces buffering to compensate for jitter it should never have received in the first place.

Packaging Without Giving Up the Segment

HLS and DASH remain the right choice for reach, every device plays them without a custom client, but standard segment durations are where a lot of "why does our stream lag six seconds behind the venue" complaints come from. Brutus Cloud's live path restreams a single SRT, RTMP, or HLS ingest out to SRT, RTMP, HLS, or DASH simultaneously, transcoding to H.264, H.265, or AV1 across multiple resolutions in the same pass. That matters here specifically because it means the low-latency leg (SRT or RTMP, for viewers on a proprietary player or a partner CDN) and the reach leg (HLS/DASH, for viewers on whatever device they picked up) can run off the same ingest instead of forcing a single, latency-compromised profile for both audiences.

What This Means for Live Event Platforms

For a platform built around live events specifically, sports, esports, concerts, the latency budget isn't abstract, it's the gap between a second-screen stat update and the play it's describing, or between a chat reaction and the moment that triggered it. Getting the encode, transport, and packaging legs each running at their lowest viable latency, rather than optimizing one stage in isolation, is what closes that gap to something an audience doesn't notice.

Talk to an Engineer about the latency budget on your delivery chain.