MOQ vs WebRTC vs HLS vs DASH vs SRT vs RIST: A Protocol Decision Guide
Choosing the wrong streaming protocol costs real money. This practical guide compares six protocols across latency, scalability, browser reach, interactivity, CDN fit, and operational complexity—with concrete recommendations for large-scale live sports, video conferencing, voice AI, broadcast contribution, and VOD.
Choosing the wrong streaming protocol costs real money. A broadcast CDN optimized for HLS cannot deliver sub-second latency. A WebRTC mesh collapses at 10,000 concurrent viewers. A voice AI pipeline built on HLS adds two seconds of latency that makes conversation feel broken. Every protocol was designed to solve a specific set of constraints—and each fails outside its design envelope.
This guide cuts through the noise. We compare six protocols across the dimensions that matter most for production decisions, then give concrete recommendations for five high-stakes scenarios.
The Six Protocols at a Glance
HLS (HTTP Live Streaming) — Apple's 2009 spec, now universal. Segments media into small chunks (typically 2–10 seconds) delivered over standard HTTP. Supported everywhere. Latency: 6–30 seconds with conventional tooling, ~2–4 seconds with Low-Latency HLS (LL-HLS).
DASH (Dynamic Adaptive Streaming over HTTP) — The ISO/IEC 23009 standard equivalent of HLS. Also chunk-based over HTTP, with superior DRM flexibility (CENC) and a richer manifest format. Latency and scalability characteristics are nearly identical to HLS.
WebRTC — IETF/W3C standard for real-time browser communication over UDP/DTLS/SRTP. Sub-300ms latency when working well. Browser-native. Struggles with scale because media flows peer-to-peer or through Selective Forwarding Units (SFUs) that fan out to individual connections.
SRT (Secure Reliable Transport) — Haivision's open-source protocol built on UDP with ARQ retransmission. Designed for first-mile contribution: sending a camera feed from a remote location to an ingest point over hostile networks. Typically not used for last-mile delivery.
RIST (Reliable Internet Stream Transport) — VSF/SMPTE TR-07 spec, conceptually similar to SRT: low-latency, reliable UDP transport for contribution and distribution links. Favored in broadcast facilities for its standards-committee pedigree and interop testing.
MOQ (Media over QUIC Transport) — IETF working group draft (moq-transport). Delivers named media objects over QUIC streams with pub/sub semantics. Aims to unify contribution and delivery, offering WebRTC-class latency with CDN-class scale. Still in active standardization as of early 2026.
Comparison Table
| Protocol | Typical Latency | Viewer Scale | Browser Native | Interactivity | CDN Fit | Operational Complexity |
|---|---|---|---|---|---|---|
| HLS | 6–30s (LL-HLS: 2–4s) | Millions | Yes (via JS) | None | Excellent | Low |
| DASH | 6–30s (LL-DASH: 2–4s) | Millions | Yes (via JS) | None | Excellent | Medium |
| WebRTC | < 300ms | ~1,000–10,000 | Yes (native) | Full duplex | Poor | High |
| SRT | 100ms–2s | Thousands (P2P) | No | None | Partial | Medium |
| RIST | 100ms–2s | Thousands (P2P) | No | None | Partial | Medium |
| MOQ | 200ms–2s† | Millions† | Partial†† | Partial†† | Good† | Medium† |
† MOQ figures are design targets, not yet proven at scale in production deployments. †† Browser support requires QUIC WebTransport; not available in all environments.
Key dimensions explained
Latency refers to glass-to-glass time under typical network conditions. "Typical" means a well-configured deployment, not best-case benchmarks.
Viewer scale reflects the practical ceiling before the architecture needs fundamental rethinking. HLS and DASH scale to millions because every CDN edge caches the same segments. WebRTC requires per-viewer connections at the SFU.
CDN fit measures how naturally the protocol maps to existing CDN infrastructure. HLS/DASH segments are plain HTTP objects—CDN POPs cache and serve them without modification. MOQ's named objects and QUIC relay model can work with CDN-adjacent infrastructure but requires QUIC-aware relays. WebRTC and SRT/RIST were not designed for CDN delivery.
Interactivity covers whether the protocol supports upstream data from viewer to sender—critical for conferencing, polling, timed metadata, or voice AI.
When to Use What: Five Scenarios
1. Large-Scale Live Sports (50,000–10M concurrent viewers)
Use: HLS or DASH
At this scale, CDN cacheability is everything. A single encoder pushes one stream; the CDN clones it to millions. LL-HLS or LL-DASH gets you to 2–4 seconds of latency, which is acceptable for sports where "near-live" is the expectation.
WebRTC cannot serve this audience without an enormous SFU farm, and the per-connection overhead makes cost-per-viewer unacceptable. MOQ is a future candidate here—its pub/sub relay model was designed for exactly this pattern—but today there are no CDN providers delivering MOQ at sports-broadcast scale.
Practical choice: LL-HLS with CDN (Akamai, Fastly, Cloudflare) for broadest reach. Add LL-DASH for Smart TV apps requiring CENC DRM.
2. Video Conferencing (2–200 participants)
Use: WebRTC
Video conferencing requires full-duplex, sub-300ms latency, and browser-native support without plugins. WebRTC is the only protocol here. Every major conferencing platform (Zoom, Google Meet, Teams) uses WebRTC under the hood.
SRT/RIST cannot run in browsers. HLS/DASH add too much latency for natural conversation. MOQ's design includes interactivity primitives but lacks the mature client library ecosystem and the signaling conventions that make WebRTC deployable today.
Practical choice: WebRTC with a cloud SFU (LiveKit, Daily, Mediasoup). For >500 participants, consider cascading SFUs or CDN-assisted fanout.
3. Voice AI / Real-Time AI Audio Processing
Use: WebRTC
Voice AI—speech-to-text, real-time translation, AI voice agents—requires getting audio to the model and back in under 500ms total round trip. Every 100ms of added latency degrades the perception of naturalness in conversation.
WebRTC's DataChannel and audio tracks deliver audio to a server in real time. The key here is not just latency but the ability to stream audio bidirectionally with precise timing. HLS batches audio into chunks; you cannot send a partial sentence to a transcription model and get a response before the chunk closes.
MOQ shows promise for voice AI: its object-level granularity means you could publish individual audio frames rather than waiting for a chunk boundary. But production SDKs for this use case do not exist yet.
Practical choice: WebRTC with a server-side audio pipeline. Use Daily, LiveKit, or Twilio Media Streams for managed infrastructure. Revisit MOQ for this use case in 12–18 months.
4. Broadcast Contribution (Camera to Ingest, WAN Links)
Use: SRT or RIST
Getting a live camera feed from a remote location to a central ingest point over the public internet is SRT and RIST's sweet spot. Both provide:
- Reliable delivery over packet-lossy UDP links
- Encryption in transit
- Sub-second latency
- Hardware encoder/decoder support from every major broadcast vendor (Haivision, VideoLAN, Matrox, Grass Valley)
SRT has broader installed base and more open-source tooling (FFmpeg integration is mature). RIST is preferred in facilities where interoperability testing via VSF/EBU test events matters.
Neither protocol is designed for last-mile delivery at scale. Once the feed arrives at your ingest point, transcode and package to HLS/DASH for distribution.
Practical choice: SRT for new deployments with a mix of hardware and software encoders. RIST for broadcast facilities with existing RIST infrastructure or strict interop requirements.
5. Video-on-Demand (VOD)
Use: DASH or HLS
VOD has no latency requirement. The priority is adaptive bitrate (ABR), DRM, codec flexibility, and platform reach.
DASH with CENC DRM is the better technical choice for VOD: it supports multi-DRM (Widevine, PlayReady, FairPlay) from a single encrypted asset, has a richer manifest structure, and is the default for CMAF-based workflows. HLS is required for Apple platforms and older iOS devices.
In practice, most large VOD providers (Netflix, Disney+, Prime Video) package in both HLS and DASH and serve based on the player/platform.
WebRTC, SRT, RIST, and MOQ are not appropriate for VOD.
Practical choice: Package in CMAF with both HLS and DASH manifests. Use Shaka Player or hls.js for web playback.
Where MOQ Fits Today—and Where It's Still Immature
MOQ (Media over QUIC Transport) is the most architecturally interesting development in streaming protocols since WebRTC. The core idea: treat media as a pub/sub system of named objects delivered over QUIC streams, where relays cache and forward objects without understanding the media format. This separates the delivery layer from the media layer in a way that HLS/DASH (which tie packaging format to delivery semantics) do not.
Where MOQ is promising
Unified contribution and delivery: Today, a live stream typically uses SRT for contribution, then transcodes to HLS for delivery—two different protocol stacks, two latency stages, two operational domains. MOQ's design allows the same QUIC-based transport to carry content from encoder to CDN relay to viewer, potentially cutting end-to-end latency and simplifying the pipeline.
Sub-second delivery at CDN scale: This is the gap in the market MOQ is designed to fill. WebRTC achieves sub-second but cannot scale. HLS/DASH scale but cannot achieve sub-second. MOQ's relay model is designed to provide both—simultaneously.
Interactivity at scale: MOQ's pub/sub primitives allow viewers to send data upstream, enabling interactive live experiences (polling, reactions, timed triggers) without separate WebSocket infrastructure.
Where MOQ is not ready
No production CDN support: As of early 2026, no major CDN (Cloudflare, Akamai, Fastly, AWS CloudFront) offers MOQ relay infrastructure. You would need to build and operate your own relay network.
Immature client ecosystem: Browser support requires WebTransport, available in Chrome and Edge but not Safari. Mobile SDKs are in early stages. The reference implementations (moq-rs, moq-go) are not production-hardened.
Standard still in flux: The IETF moq-transport draft continues to evolve. The object model, prioritization semantics, and relay behavior are not fully settled. Building production infrastructure on a moving spec carries risk.
No finalized ABR specification: Adaptive bitrate streaming—fundamental for variable network conditions—does not yet have a stable MOQ-level specification. This is being worked on but is not settled.
Operational unknowns: Monitoring, debugging, capacity planning, and incident response for MOQ deployments are not yet established disciplines. Your team will be building these playbooks from scratch.
The honest timeline
For most production use cases in 2026, MOQ is a technology to watch and prototype with, not deploy for primary traffic. The realistic window for MOQ to displace HLS for large-scale live delivery is 2027–2029, contingent on CDN adoption and spec stabilization. For niche use cases with controlled environments—closed enterprise networks, in-stadium delivery, early-adopter developer platforms—MOQ can be evaluated today.
Quick Decision Flowchart
- Sub-300ms latency required? → WebRTC
- >10,000 concurrent viewers? → HLS or DASH
- Point-to-point contribution over hostile networks? → SRT or RIST
- VOD with DRM? → DASH (+ HLS for Apple)
- Prototyping the future of streaming? → MOQ
Summary
No single protocol wins across all dimensions. The practical hierarchy for 2026 deployments:
| Use Case | Protocol |
|---|---|
| Real-time conferencing / voice AI | WebRTC |
| Large-scale live delivery | HLS / DASH |
| VOD | DASH (+ HLS) |
| Broadcast contribution / WAN links | SRT / RIST |
| R&D, prototyping, early production | MOQ |
The biggest unmet need in streaming—sub-second delivery at CDN scale—is exactly what MOQ is designed to solve. The spec is maturing, the first implementations are shipping, and the CDN ecosystem is watching. MOQ is not ready to replace HLS today. It will be.