1. Context of the Problem (2019-2023)
Between 2019 and 2023, the live video broadcast industry underwent a paradigm shift. Content creators, premium OTT networks, and live event promoters demanded ultra-low-latency, interactive streaming experiences. The standard goal was to achieve "glass-to-glass" latency (the time from a camera lens capturing a frame to a viewer seeing it on their screen) of under 2.0 seconds. However, delivering high-bitrate contribution feeds reliably over public internet networks remained highly volatile, prone to dynamic packet loss, jitter, and congestion. Standard transmission protocols lacked the error-correction efficiency or scalability required for concurrent multi-destination syndication.
2. Evaluation of Available Options
During the research phase, three primary architectural patterns were evaluated for contribution and edge distribution:
| Protocol / Option | Pros | Cons | Suitable Use Case |
|---|---|---|---|
| Option A: Traditional RTMP (over TCP) | Universal software and hardware encoder support; simple firewall configuration. | TCP head-of-line blocking; stream disconnections or severe buffering if packet loss exceeds 3%. | Legacy ingest only; unsuitable for low-latency or unstable networks. |
| Option B: WebRTC (over UDP) | Sub-second sub-500ms interactive latency; supported natively in standard browsers. | Computationally expensive to scale; lacks linear TV syndication profiles (SDI/NDI output mapping). | Interactive peer-to-peer chats and highly localized small-audience feeds. |
| Option C: SRT Ingest + LL-HLS Edge (UDP Contribution) | Selective ARQ packet recovery; resilient over volatile networks; ultra-low-latency packaging. | Requires custom jitter-buffer tuning; more complex player support integration. | High-concurrency global OTT and TV channel syndication. Chosen Option. |
3. Architectural Selection Rationale
Option C was engineered as the optimal architecture. Option A (RTMP) was rejected because it is fundamentally limited by TCP's congestion-control behavior. Under 5% packet loss, RTMP's buffer queue spirals out of control, introducing seconds of latency and leading to complete feed failure. Option B (WebRTC) was rejected. While excellent for sub-second peer-to-peer latency, WebRTC's opaque internal congestion algorithms are notoriously difficult to tune for broadcast. More critically, operating stateful SFUs (Selective Forwarding Units) for 25,000+ concurrent viewers scales exponentially in compute cost and cannot natively integrate with established linear television satellite and cable receivers.
By implementing Option C, Secure Reliable Transport (SRT) is used for the contribution feed. SRT, open-sourced by Haivision in 2017 and maintained by the SRT Alliance, utilizes UDP with selective ARQ (Automatic Repeat reQuest). It isolates packet loss recovery within a configured latency budget, preventing network retransmission delays from blocking subsequent frames. The ingest layer is backed by Go-based streaming managers running on AWS ECS (Fargate) with containerized FFmpeg pipelines, transcoding SRT feeds into multi-bitrate HTTP Live Streaming (HLS) and LL-HLS targets distributed globally via AWS CloudFront with Origin Shield.
4. Stress-Testing, Chaos Injection & Telemetry
To validate the resilience of this pattern under public internet conditions, artificial impairments were introduced at the ingest interface using Comcast NetEm. Packet loss of up to 35%, 200ms latency jitter, and out-of-order delivery were injected. Concurrently, 30,000 headless players were simulated via distributed Locust container tasks to stress-test origin capacity and edge cache hit ratios.
| Experimental Parameters | |
|---|---|
| Video Bitrate (1080p60 Ingest) | 6.0 Mbps to 12.0 Mbps (H.264 / AAC) |
| Network Latency / RTT | 50ms to 250ms (simulated WAN) |
| Packet Loss Ratio | 0% to 35% (continuous / bursty) |
| Ingest Packet Jitter | ±20ms to ±200ms (NetEm) |
| SRT Transmission MTU | 1500 bytes (standard UDP payload) |
| Test Run Duration | 120-hour continuous stability loops |
The telemetry recorded during these test iterations:
- Selective Retransmission Efficiency: Under the tested conditions, SRT successfully recovered 100% of packets under up to 25% simulated packet loss, preserving a pristine, zero-frame-drop broadcast. In parallel testing, RTMP became unstable at approximately 4% packet loss.
- Optimal Jitter-Buffer Bounds: Testing confirmed that a configured ingest buffer of 4× RTT produced the desired tradeoff under tested network conditions, sustaining an end-to-end glass-to-glass latency of under 2.0 seconds with zero buffering events.
- Origin Isolation: CloudFront Origin Shield successfully collapsed edge cache request loops, sustaining a 99.8% cache hit ratio and reducing origin egress load by 84% under a peak concurrent viewer load.
5. Limitations
While the proposed architecture exhibits high resilience and low latency, several key engineering limitations must be factored into production deployments:
- Selective ARQ Overhead: Under extremely high packet loss conditions (exceeding 30%), the network overhead of selective retransmission requests (ARQ) can saturate the upload link, resulting in reduced effective throughput.
- LL-HLS Client Compatibility: Older hardware players, legacy smart TVs, or outdated mobile browsers may not support low-latency HTTP Live Streaming extension tags natively, reverting to standard HLS with 6s+ latencies.
- Complex Buffer Trade-Offs: Determining the optimal jitter-buffer size requires dynamic adjustment. Underestimating latency targets leads to packet dropouts, while overestimating buffer sizes degrades the interactive under-2s glass-to-glass latency target.
6. Architectural Conclusions
This architecture case study demonstrates that software-defined live-video syndication pipelines utilizing SRT over public networks are highly resilient and cost-effective compared to traditional RTMP or legacy hardware appliances. By decoupling ingestion reliability from network quality, broadcast networks can achieve robust, zero-frame-drop syndication directly to linear channels (linear broadcast channels) and global digital audiences, while maintaining full ownership of operational unit costs.