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.