Live Streaming Architecture and Infrastructure

Live streaming adds real-time constraints to video infrastructure. Unlike VOD, you can't pre-process—everything happens in real-time.

Architecture layers: 1. Ingest: Receive stream from broadcaster 2. Transcoding: Convert to ABR renditions in real-time 3. Packaging: Generate HLS/DASH segments and manifests 4. Delivery: Distribute via CDN to viewers 5. Playback: Player adapts to conditions

Key metrics: - Glass-to-glass latency: Time from camera to viewer screen - Stream reliability: Uptime, error rate - Concurrent viewers: Scale capacity - Quality consistency: Bitrate stability, buffering rate

The ingest layer receives video from streamers and prepares it for transcoding.

Ingest protocols:

RTMP (Real-Time Messaging Protocol) - Industry standard, widely supported by encoders - TCP-based, struggles on poor networks - Typically 3-5 second latency to origin

SRT (Secure Reliable Transport) - Better performance on unstable networks - Built-in encryption - Lower latency than RTMP - Growing adoption in professional broadcasting

WebRTC - Sub-second ingest latency - Browser-native (no encoder software needed) - Complex infrastructure requirements

Ingest architecture: - Multiple regional ingest points - Automatic failover if primary fails - Health monitoring and alerting - Stream key authentication

Origin servers transcode the ingest stream to multiple ABR renditions in real-time.

Transcoding requirements: - Encoding speed must exceed real-time (1x minimum) - Consistent keyframe intervals across renditions - Low latency encoding settings - Redundant transcoding for critical streams

Packaging output: - Generate HLS and/or DASH segments - Update manifests every segment (2-6 seconds) - DVR: Extend manifest window, retain segments - Thumbnail generation for preview

Redundancy patterns: - Active-passive: Standby transcoder takes over on failure - Active-active: Both process, CDN selects healthy - N+1: Extra capacity for failover

Origin architecture: - Stateless transcoding containers - Shared segment storage (S3, GCS) - Manifest generation at edge or origin - Health checks and automatic failover

Standard HLS/DASH has 15-30 second latency. Reducing latency requires changes across the stack.

Latency reduction techniques:

Shorter segments (2s instead of 6s) - Reduces theoretical minimum latency - Increases manifest update frequency - More CDN requests, slightly higher costs

Chunked transfer encoding (CMAF-CTE) - Stream segment data as it's encoded - Player can start before segment complete - Requires CDN and player support

LL-HLS and LL-DASH - Apple's Low-Latency HLS specification - Partial segments and blocking playlist requests - 2-4 second latency achievable - Requires compatible players and CDN

WebRTC for sub-second latency - Direct peer or media server delivery - Best for <1 second latency requirements - Scales differently than HTTP (more complex) - Good for: interactive streams, auctions, gaming

DVR functionality allows viewers to pause, rewind, and catch up on live streams.

DVR implementation: - Extend manifest window (e.g., 4 hours instead of 30 seconds) - Retain segments in storage with lifecycle policies - Track live edge vs playback position - Handle manifest requests for historical content

Catch-up/Start-over: - Allow starting from beginning of live event - Seamless transition from catch-up to live - Progress tracking across sessions

Storage considerations: - Segment retention policies (hours, days, permanent) - Storage tier selection (hot during event, archive after) - Cost modeling for DVR window length

Clipping and highlights: - Extract clips from live stream - Generate permanent VOD from live segments - Timeline-based clip selection interface

Scaling to millions of concurrent viewers requires careful architecture at every layer.

CDN configuration for live: - Shorter cache TTLs (segment duration) - Negative caching for manifest 404s - Shield/mid-tier caching to reduce origin load - Geographic distribution for global events

Origin scaling: - Manifest generation is the bottleneck - Cache manifests at edge with short TTL - Consider edge-side manifest generation - Separate origin clusters per stream

Capacity planning: - Peak concurrent viewers per stream - Total streams across platform - Geographic distribution of viewers - Bandwidth per viewer (ABR profile)

Managed solutions: - AWS IVS: Fully managed, low-latency option - Mux Live: Simple API, good developer experience - Cloudflare Stream Live: Competitive pricing - Wowza: Self-hosted or cloud options

For most use cases, managed live streaming services provide the fastest path to production with built-in scale and reliability.