Live video streaming has become the backbone of modern entertainment infrastructure. Whether a user is watching a football match, joining a video conference, or consuming on-demand content, the underlying delivery pipeline is an extraordinary feat of distributed systems engineering.
Yet most developers treat streaming as a black box. You point a video player at a URL and it works. But how does a single origin server deliver 4K video to millions of concurrent viewers without collapsing? How does the player seamlessly switch between 480p and 4K mid-stream without buffering? And why does the same stream load in 200ms in Dublin but take 4 seconds in rural Kerry?
This article breaks down the complete architecture - from ingest to last-mile delivery - with real protocol analysis and code examples.
Every live video stream traverses five distinct architectural stages before reaching the viewer's screen:
Originally developed by Macromedia (later Adobe), RTMP operates over TCP port 1935. Despite being officially deprecated, it remains the de facto ingest protocol for most streaming infrastructure due to its universal encoder support.
SRT is the modern successor, developed by Haivision. It operates over UDP with built-in AES-128/256 encryption and Forward Error Correction (FEC). SRT's killer feature is its adaptive bitrate recovery - it dynamically adjusts packet retransmission based on measured round-trip time (RTT), making it exceptionally resilient over unreliable WAN links.
A single 4K ingest feed must be transcoded into multiple renditions to serve the diverse range of client devices and network conditions. This set of parallel encodes is called the ABR Ladder (Adaptive Bitrate Ladder).
| Rendition | Resolution | Bitrate | Codec | Use Case | |-----------|-----------|---------|-------|----------| | UHD | 3840x2160 | 15 Mbps | H.265/HEVC | Smart TV, Console | | FHD | 1920x1080 | 6 Mbps | H.264/AVC | Desktop, Tablet | | HD | 1280x720 | 3 Mbps | H.264/AVC | Mobile (Wi-Fi) | | SD | 854x480 | 1.5 Mbps | H.264/AVC | Mobile (4G) | | Low | 640x360 | 800 Kbps | H.264/AVC | Weak connections |
Key parameters explained: -g 48: GOP (Group of Pictures) size. At 24fps, this creates a keyframe every 2 seconds - critical for clean ABR switching. -scthreshold 0: Disables scene-change detection to enforce consistent GOP boundaries. -hlstime 6: Each HLS segment is exactly 6 seconds long.
Once transcoded, the renditions must be packaged into a streaming format that HTTP-based CDNs can cache and serve. Two protocols dominate.
Developed by Apple (RFC 8216), HLS is the universal standard. It works by slicing the continuous video stream into small .ts (Transport Stream) or .fmp4 (Fragmented MP4) files, each typically 2-6 seconds long. A plain-text .m3u8 manifest file acts as the index.
DASH (ISO/IEC 23009-1) is the open, vendor-neutral alternative. Instead of .m3u8, it uses an XML-based Media Presentation Description (.mpd). DASH exclusively uses .mp4 containers (no .ts), which reduces overhead.
| Feature | HLS | DASH | |---------|-----|------| | Apple device support | Native | Requires MSE | | DRM support | FairPlay | Widevine, PlayReady | | Container format | .ts or .fmp4 | .mp4 only | | Latency (standard) | 15-30s | 10-20s | | Low-latency mode | LL-HLS (~3s) | LL-DASH (~3s) | | Industry adoption | Universal | YouTube, Netflix |
In practice, most production deployments generate both formats simultaneously from the same transcoded renditions.
This is where the real magic happens. A Content Delivery Network caches the video segments at geographically distributed Points of Presence (PoPs), eliminating the round-trip latency to the origin server.
For a 2-hour live stream with 6-second segments, that's 1,200 segment requests per viewer. With a CDN, only the first viewer triggers an origin pull. Every subsequent viewer on the same edge node receives the segment from local cache in single-digit milliseconds.
The key insight: manifest files change every segment duration (they point to new segments), so they need ultra-short cache TTLs. But the segments themselves are immutable - they can be cached aggressively.
Ireland's internet infrastructure has a unique characteristic that directly impacts streaming performance: INEX (Internet Neutral Exchange). INEX operates two major peering facilities: INEX Dublin (Equinix DB3, Interxion DUB1/DUB2) INEX Cork (Equinix CK1)