DEVBOOK

Live Streaming

4 min read

Edit this pageReport / suggest

Live streaming moves audio and video from a live encoder to many viewers while the program is still being produced. The working path is ingest → transcode → package → origin → CDN → player. Each stage trades latency against quality, reach, and failure isolation. A sports stream may accept 8–15 seconds to gain CDN scale; a live auction may need WebRTC-class latency and accept a more expensive distribution model.

End-to-End Path

  1. Capture and ingest. The encoder compresses camera and microphone input and sends a contribution stream to an ingest edge. RTMP is still common in encoder ecosystems; SRT and WebRTC/WHIP address loss recovery or lower-latency ingest.
  2. Transcode. The service decodes the contribution feed and produces an aligned bitrate ladder, for example 1080p at 6 Mb/s, 720p at 3 Mb/s, and 480p at 1.2 Mb/s. Keyframes must align across renditions so a player can switch without corrupting the timeline.
  3. Package. A packager writes short media segments or chunks plus manifests. HLS uses playlists; MPEG-DASH uses an MPD. CMAF fragmented MP4 can let both protocols share media objects when codec and profile choices overlap.
  4. Origin and CDN. The origin exposes manifests and new media objects. CDN edges cache them and collapse simultaneous misses instead of sending every viewer to the packager.
  5. Player. The player estimates throughput and buffer health, selects a rendition, downloads segments, decodes them, and moves up or down the ladder before playback stalls.
camera -> encoder -> ingest -> transcoder -> packager -> origin -> CDN edge -> player
                          \-> archive/object storage -> replay/VOD manifest

Latency Is a Budget

A six-second segment cannot usually deliver sub-second glass-to-glass latency: the encoder must fill it, the packager must publish it, the CDN must fetch it, and the player normally buffers more than one segment. Shorter segments or partial segments reduce wait time but increase request rate, manifest churn, cache pressure, and sensitivity to jitter.

Low-Latency HLS and low-latency DASH publish chunks before a full segment closes. WebRTC sends media continuously and handles congestion interactively, making it a better fit for calls, auctions, and remote control. It costs more per viewer because the delivery path cannot rely on ordinary immutable HTTP objects as effectively.

Protocol Compatibility

ProtocolTypical roleBrowser/device boundary
RTMPEncoder-to-ingest contributionNot a modern browser playback protocol; retain it where encoder support matters
SRTLoss-tolerant contribution over uncontrolled networksCommon between encoders and media infrastructure, not native browser playback
HLSAdaptive HTTP playbackNative on Apple platforms; other browsers commonly use Media Source Extensions through a JavaScript player
MPEG-DASHAdaptive HTTP playbackCommon through Media Source Extensions; Safari support depends on player and codec/container choices
WebRTC with WHIP/WHEP-style signalingInteractive ingest or playbackBrowser-native media stack with sub-second goals; harder CDN economics and session state

Do not infer compatibility from the manifest name alone. Codec, profile, encryption, container, captions, and DRM support can rule out a device even when it understands HLS or DASH.

Failure Boundaries

  • Keep the last valid manifest available briefly when the packager restarts; a malformed or empty live manifest can drop every player at once.
  • Measure capture timestamp to playback timestamp, not only CDN request latency.
  • Preserve monotonic timestamps and aligned keyframes across failover encoders.
  • Apply backpressure or drop frames deliberately; an unbounded ingest queue converts overload into ever-growing live latency.
  • Separate the live path from replay finalization so a storage outage does not stop the broadcast.

References

Graph View

Backlinks