Evaluated October 2026, the answer for most pipelines is the same: send video into your platform with SRT or RTMP, deliver it to viewers with HLS or DASH over HTTP, and use WebRTC only where viewers interact in real time. The split matters because streaming protocols differ by more than an order of magnitude in latency, from roughly 25 seconds for default HLS to under half a second for WebRTC. They also differ in how they scale. Only the HTTP-based formats reach millions of concurrent viewers through ordinary CDN caching.
As of 2026, HLS (RFC 8216) with 6-second segments typically delivers 15 to 30 seconds of glass-to-glass latency, Low-Latency HLS and low-latency DASH reach about 2 to 5 seconds, and WebRTC stays under 500 milliseconds. RTMP and SRT now work almost only as ingest protocols. No mainstream browser has played RTMP since Adobe ended Flash support in December 2020.
A live pipeline has two network legs with opposite requirements. The contribution leg, also called first mile or ingest, carries one high-bitrate stream from an encoder to a media server. It needs loss recovery and low delay over a single path that is often unreliable. The distribution leg carries many lower-bitrate renditions to thousands or millions of players. It needs device compatibility and cacheability.
RTMP, SRT and WebRTC (through WHIP, the WebRTC-HTTP Ingestion Protocol, RFC 9725) compete on the first leg. HLS, MPEG-DASH and WebRTC compete on the second. WebRTC is the only one that credibly does both, and that is why it keeps appearing in architectures that need interaction more than reach.
These are the criteria that change the decision for video streaming protocols, roughly in the order evaluation teams hit them:
| Protocol | Main role | Typical latency | Transport | Player reach | Scale model |
|---|---|---|---|---|---|
| HLS | Playback | 15 to 30 s default; 2 to 5 s as LL-HLS | HTTP over TCP or QUIC | Native on Apple devices, MSE elsewhere | Cached segments, audience-independent origin load |
| MPEG-DASH | Playback | 10 to 30 s default; 2 to 5 s as LL-DASH | HTTP over TCP or QUIC | MSE browsers, Android, most smart TVs; weak on Apple | Cached segments |
| RTMP | Ingest | 1 to 5 s on the ingest leg | TCP, port 1935 | Every encoder and social platform; no browsers | One session per stream |
| SRT | Ingest and contribution | Configured buffer, 120 ms default, often 3 to 4 times RTT | UDP with ARQ and AES encryption | Broadcast encoders, OBS, cloud media services; no browsers | One session per stream |
| WebRTC | Ingest (WHIP) and real-time playback | 0.2 to 0.5 s | UDP with SRTP and DTLS | All modern browsers natively | Stateful per-viewer sessions on SFUs |
The latency gap between protocols comes mostly from segment duration and player buffering, not from the wire format, which is why tuned HLS closes most of the distance to RTMP-era latency.
HLS is the default playback format because it plays natively on every Apple device and through MSE players everywhere else. It is also the only route to FairPlay DRM on Apple hardware. LL-HLS adds partial segments, typically 200 ms to 1 s, along with blocking playlist reloads and preload hints, while staying cacheable. Limitation: LL-HLS multiplies playlist requests per viewer, and a CDN that does not hold blocking playlist requests or coalesce them sends that load straight to the origin.
DASH (ISO/IEC 23009-1) is codec-agnostic and is the natural carrier for Widevine and PlayReady. Low-latency DASH streams CMAF chunks over HTTP chunked transfer. Limitation: Apple support remains the weak spot. Safari on iPhone only gained Managed Media Source in iOS 17.1, and AVPlayer, Apple TV and many existing apps still expect HLS, so few services ship DASH alone.
RTMP survives because every encoder, from OBS to hardware boxes, speaks it, and every major social platform accepts it. The Enhanced RTMP specification from 2023 added HEVC, VP9 and AV1. Limitation: it runs over TCP, so on lossy long-haul links head-of-line blocking stalls the stream and the encoder buffer grows until frames drop.
SRT (Secure Reliable Transport) was open-sourced in 2017. It runs over UDP, retransmits lost packets within a configured latency window, and encrypts with AES-128 or AES-256. Over the public internet it replaces satellite and dedicated fiber for contribution in many broadcast workflows. Limitation: it trades bandwidth for reliability. The default overhead allowance is 25% above the stream bitrate, and if loss exceeds what the latency window can repair, packets are dropped instead of delayed.
WebRTC is the only browser-native option under one second, and WHIP has made it a standard ingest path that OBS has supported since version 30. Limitation: media is encrypted per session with SRTP, so a CDN cannot cache it. Every viewer is a stateful connection on an SFU, and the fleet must be built for the peak audience.
HLS and RTMP rarely compete in 2026 because they sit on different legs of the pipeline. RTMP carries one stream from the encoder to an ingest server, and HLS carries packaged renditions from a CDN to players. The real choices are RTMP versus SRT for ingest and HLS versus DASH or WebRTC for playback.
Teams that remember RTMP playback as "low latency" usually compare it against HLS with 10-second segments. A 1-second HLS part target puts HTTP delivery in the same 2 to 5 second band that Flash-era RTMP playback offered, and it keeps the caching economics.
WebRTC beats HLS on latency by roughly 10 to 50 times, but HLS beats WebRTC on cost per viewer because cached segments are served to every viewer from the same objects. The breakeven depends on whether sub-second delay changes the product, as in auctions, betting, watch parties or two-way video, or only improves it.
This blog's latency budget model for HTTP delivery is encode and ingest time, plus one segment or part to package, plus the player hold-back of three target durations, which the HLS specification sets as the minimum distance from the live edge:
The capacity side starts from the same egress either way. 100,000 concurrent viewers at an average of 3 Mb/s is 300 Gb/s. One hour of that is 300 Gb/s times 3,600 s, which equals 1,080,000 gigabits, or 135 TB. With HLS, the origin shield sees about 5 renditions times 0.5 segment requests per second for 2-second segments, about 2.5 requests per second plus playlists, whether the audience is 1,000 or 1,000,000. With WebRTC, our estimate is that an SFU forwarding about 5 Gb/s needs around 60 servers, plus cascading between them, to carry the same 300 Gb/s. Every one of those servers holds per-viewer state.
| Workload | Ingest | Playback | Why |
|---|---|---|---|
| VOD library, OTT catalog | File upload | HLS and DASH from shared CMAF | Full device and DRM coverage, one set of segments |
| Large live events, sports | SRT from venue | LL-HLS, 2 to 5 s | Loss-tolerant contribution, cacheable fan-out |
| Creator and social streaming | RTMP, moving to SRT or WHIP | HLS | Encoder ubiquity matters more than first-mile resilience |
| Betting, auctions, watch parties | WHIP or SRT | WebRTC | Sub-second delay is the product |
| Broadcast remote production | SRT | Internal SRT or HLS | Encryption and ARQ over the public internet |
For every workload except real-time interaction, the winning pattern is a UDP-based or RTMP ingest leg feeding HTTP segment delivery.
On the delivery leg, the BlazingCDN HLS Streaming CDN for LL-HLS and DASH delivery serves pre-encoded HLS, LL-HLS and DASH with origin shield and request coalescing included, which absorbs the playlist load that low-latency modes create. It does not accept RTMP ingest or transcode video, so the contribution leg ends at your own encoder and packager, and the CDN starts at the HTTP segments.
WebRTC has the lowest latency of the common streaming protocols, typically 0.2 to 0.5 seconds glass-to-glass in browsers. The cost is scale: each viewer holds a stateful encrypted session on a selective forwarding unit, so delivery cannot use ordinary CDN caching. Low-Latency HLS at 2 to 5 seconds is the cacheable alternative for large audiences.
RTMP is still worth using for ingest when encoder compatibility matters most, because nearly every encoder and social platform accepts it. It runs over TCP, so lossy long-distance links cause stalls. For contribution over unreliable networks, SRT or WebRTC through WHIP recovers packet loss more gracefully. Browsers have not played RTMP since Flash ended in December 2020.
Use SRT when the path crosses the public internet with measurable packet loss or high RTT, and RTMP when the target platform only accepts RTMP. SRT retransmits lost packets within a configured latency buffer, commonly three to four times RTT, and adds AES encryption. Budget roughly 25% extra bandwidth for SRT retransmission overhead.
HLS and DASH can share the same segments when both use CMAF fragmented MP4, so only the HLS playlist and the DASH manifest differ. That roughly halves segment storage and doubles cache efficiency compared with separate MPEG-TS and MP4 outputs. DRM still needs care, because FairPlay uses CBCS encryption, which older Widevine and PlayReady clients may not support.
Before you change protocols, measure what you have. Burn a wall-clock timecode into a test stream, film the player next to the source clock, and record glass-to-glass latency at your current segment duration. Then repeat the test with 2-second segments and with LL-HLS at 0.5 to 1 second parts. Alongside latency, track origin request rate per second at the shield and player rebuffer ratio, because those two numbers show what lower latency actually costs you. Most teams find that segment tuning reaches their latency target without WebRTC.
If your packaged HLS or DASH segments need a delivery layer, the BlazingCDN Video CDN for packaged video delivery replicates your library inside the CDN and offers a 14-day testing period on real production traffic.