Live Streaming Architecture: Contribution, Packaging, and Latency Tiers

Live streaming reuses most of the VOD pipeline — transcode, package, deliver over a CDN — but adds two things that change everything: a real-time clock and a contribution leg that carries the signal from the venue to your encoders. Every architectural decision in live trades off latency, cost, and resilience.

The live pipeline

End to end, a live stream flows through:

• Contribution — the camera/encoder sends the feed to the cloud.
• Transcode — the ingest point produces the bitrate ladder in real time.
• Packaging — renditions are segmented into CMAF and described by HLS/DASH manifests that grow as new segments arrive.
• Delivery — a CDN fans the live edge out to viewers.
• Player — fetches the continuously updating manifest and plays at the live edge.

The transcode → package → deliver → player stages mirror VOD (see VOD Streaming Architecture), but they run under a deadline.

Contribution: RTMP vs SRT

The first hop carries a single high-quality feed from the source to ingest.

• RTMP — the long-standing default. Ubiquitous in encoders and software like OBS, but it runs over TCP, is limited to older codecs in practice (H.264/AAC), and degrades on lossy networks.
• SRT — a modern, open, UDP-based protocol with forward error correction and ARQ retransmission. It holds up far better over unreliable internet links and is increasingly the choice for serious contribution. RIST is a comparable alternative.

For first-mile reliability over the public internet, SRT (or RIST) is the stronger choice; RTMP remains common simply because everything speaks it.

Transcode and packaging under a deadline

Live transcoding almost always uses hardware encoders (NVENC, Quick Sync, VideoToolbox) for speed and density — quality per bit matters less than hitting the frame deadline (see Transcoding Explained). Packaging is continuous: the packager appends new CMAF segments and rewrites the manifest, advancing the live edge. Segment duration directly drives latency, which leads to the tiers below.

Latency tiers

How "live" your stream is depends on the technology, and each tier is a real trade-off against scale and cost. Approximate glass-to-glass figures:

• Traditional HLS/DASH (~15–30s) — segments of 4–6s plus a multi-segment player buffer. Maximally compatible and cheap to deliver, but seconds behind reality. Fine for most VOD-style live (concerts, lectures).
• Low-latency: LL-HLS / LL-DASH (~2–5s) — partial segments (HLS parts) and chunked-transfer CMAF push frames out before a full segment finishes, with blocking playlist reloads and preload hints. Rides existing CDN infrastructure, so it scales to large audiences while cutting latency to a few seconds. The workhorse for sports and interactive broadcast.
• WebRTC (sub-second) — a real-time peer/SFU transport built for conferencing. Genuinely interactive (auction, betting, two-way), but it does not use standard HTTP CDN caching, so scaling to huge audiences is harder and costlier.

The rule of thumb: pick the highest-latency tier your product can tolerate, because lower latency costs more in infrastructure and complexity. Most "live at scale" today lands on LL-HLS/LL-DASH.

DVR and the live window

A live manifest exposes a DVR window — the span of recent segments a viewer can seek back into. The window length is a policy choice:

• A short window (a few minutes) keeps players near the live edge and bounds storage.
• A long window (hours) lets viewers pause, rewind, and catch up, at the cost of retaining more segments.

When the event ends, the same segments can be sealed into a VOD asset — the live recording becomes an on-demand title with no re-encode.

Ad insertion and SCTE-35

Live streams carry SCTE-35 markers in the transport stream or signaled in the manifest to mark ad breaks and program boundaries. A packager translates these into manifest signaling (EXT-X-DATERANGE in HLS, DASH events) so an SSAI (server-side ad insertion) system can splice ads at the right frame. You can see how these markers appear in a real live workflow with the SSAI tools and live SCTE-35 sample.

Redundancy: never go dark

Live has no second take, so resilience is designed in at every hop:

• Redundant contribution — dual encoders or bonded/SRT links so one network failure doesn't kill the feed.
• Redundant ingest and transcode — hot-standby or active-active pipelines, often across availability zones, with automatic failover.
• Multi-CDN delivery — more than one CDN with health-based switching so a single CDN incident doesn't black out the audience.
• Manifest continuity — failover must preserve segment timing and the live edge so players don't stall or rebuffer on a switch.

The takeaway

Live streaming is the VOD pipeline plus a clock and a fragile first mile. Choose a robust contribution protocol, transcode in hardware to hit the deadline, pick the loosest latency tier your product allows, and engineer redundancy into every hop — because in live, the failure is always public.

To round out the series, revisit VOD Streaming Architecture for the on-demand counterpart and HLS vs MPEG-DASH for the delivery formats both pipelines share.