What Is Media over QUIC (MoQ)? A Technical Guide

Live streaming has lived with an awkward compromise for years. If you want genuinely low latency, you reach for WebRTC—and accept that scaling it to a mass audience is hard and expensive. If you want to reach millions of viewers reliably, you reach for HLS or DASH—and accept that even the low-latency variants usually land in the low single-digit seconds rather than under one second. Media over QUIC (MoQ) is the IETF’s attempt to remove that compromise with a single protocol.

Most platforms that need both end up stitching two different worlds together with protocol translation and custom infrastructure. This guide explains what Media over QUIC actually is, how its publish/subscribe relay model works, how it compares with the protocols you already run, and—just as importantly—how ready it really is for production.

Why QUIC Is the Foundation

MoQ is built on QUIC, and understanding why starts with a transport problem. Traditional HTTP streaming runs over TCP, which suffers from head-of-line blocking: when several logical streams share one connection, the loss of a single packet can stall unrelated streams until that packet is retransmitted. For media, where a late frame is often worse than a missing one, that behaviour is actively harmful.

QUIC runs over UDP instead and is stream-aware: it supports multiple independent streams inside one connection, so packet loss in one stream doesn’t hold up the others. Only the affected stream waits. QUIC also folds transport and encryption into a single handshake, so it can begin sending application data in fewer round trips than TCP plus TLS — which trims meaningful time off the first frame. QUIC is specified by the IETF as RFC 9000, and it’s the same transport foundation underneath HTTP/3.

A simple way to picture the difference: TCP is a single-lane road where one broken-down car blocks everyone behind it. QUIC is a multi-lane road where a stalled car in lane three doesn’t stop traffic in lanes one, two, and four. For video, that means a lost packet in one track doesn’t freeze the rest of the stream.

What MoQ Actually Is

Media over QUIC is a publish/subscribe media transport protocol that runs over QUIC or over WebTransport (which exposes QUIC to browsers). The wire protocol being standardised is formally called MoQ Transport, or MOQT. Work is happening in the IETF’s Media over QUIC working group, whose charter is to develop a simple low-latency media delivery solution for both ingest and distribution — and that phrase is the key to the whole design.

Today’s live stacks typically use one protocol to get video into the platform (RTMP, SRT, or RIST) and a completely different one to get it out to viewers (HLS or DASH). Switching protocols in the middle forces an intermediary origin that repackages the content. One of MOQT’s stated goals is convergence: a single protocol usable from contribution all the way through distribution, removing that repackaging step. Notably, despite the name, MOQT is media-agnostic — it’s a transport for timed objects, not a video-only format, which is why the same protocol is discussed for cloud gaming, telemetry, and collaboration as well as streaming.

The MoQ data model

Instead of manifests and segments, MoQ organises media as a hierarchy. At the top is a track — a named, subscribable stream of media, such as a particular video rendition or audio language. Tracks are divided into groups and subgroups, and the smallest unit is an object: an immutable, individually addressable piece of media data. Objects are what actually travel the network, and because they’re immutable, any relay can cache and forward them without needing to understand or rewrite the media inside.

This is a genuine departure from segment-based streaming. In HLS or DASH, the player fetches a manifest, learns which segment URLs exist, and requests them over HTTP — a pull model built on web semantics. In MoQ, a client subscribes to a track by name and the network pushes objects to it as they become available. There’s no manifest polling and no waiting for a segment to finish being written before it can be sent, which is where a large part of the latency advantage comes from.

Why MoQ Is Lower Latency Than HLS and DASH

It’s worth being concrete about that last point, because it’s the crux of the design. In classic segment-based delivery, a segment is a unit of both encoding and transport: the packager writes a two- or six-second chunk, and only once it is complete can it be published, requested, and delivered. Every viewer therefore inherits at least one segment duration of structural delay before the picture can even start moving, plus manifest refresh intervals on top. Low-latency HLS and DASH attack this with partial segments and chunked transfer, which helps considerably, but the segment remains the organising unit of the protocol.

MoQ removes the segment as the transport unit entirely. Because the object is small and independently addressable, media can be pushed the moment it exists rather than when a chunk boundary happens to arrive, and a relay can forward it onward immediately without waiting for anything else. Interoperability also becomes simpler in principle: any system that speaks MOQT can publish or subscribe to a track without negotiating bilaterally with the other side first, which is the property vendors are trying to build a shared ecosystem around.

Publishers, subscribers, and relays

MoQ defines three roles, and the third is the architecturally interesting one:

• Publishers announce track namespaces and send objects into the network.
• Subscribers request specific tracks by name and receive the objects for them.
• Relays sit in between, forwarding immutable objects from publishers toward subscribers — and caching them along the way.

The relay is what makes MoQ scale. A publisher does not open a separate connection to every viewer; it publishes once, and relays handle fan-out and short-term caching. Subscribers attach to a nearby relay rather than to the origin. If that sounds familiar, it should — it’s essentially CDN logic applied to real-time media: one upstream copy, local distribution, far less waste across the backbone. A frequently cited example is a branch office, where a local relay means the media crosses the wide-area link once and is then distributed internally as many times as needed.

This is precisely why MoQ has attracted interest from CDN and infrastructure vendors rather than only real-time-communications specialists. It collapses the structural difference between a WebRTC media server and an HTTP CDN into one architecture, and the argument its advocates make is that a single delivery network, protocol, and format could serve several market segments at once — which would mean lower operating cost and better capacity management than running separate stacks.

Priorities, partial reliability, and rate adaptation

One reason MoQ is built on QUIC rather than plain UDP is that it can borrow transport features that matter specifically for media. MOQT makes use of QUIC streams and datagrams, along with priorities and partial reliability — and each of those maps onto a real streaming problem.

Priorities let the sender express that some objects matter more than others. In a live stream, an audio object or a keyframe is more valuable than a late non-reference frame, and a transport that understands that can make better decisions when capacity is tight. Partial reliability matters for the same reason: in media delivery, an object that arrives too late to be displayed has no value, so being able to give up on it rather than retransmit it forever is a feature, not a failure. This is the behaviour that segment-based HTTP streaming fundamentally cannot express, because HTTP over TCP will insist on delivering every byte in order even when the deadline has already passed.

Rate adaptation works differently too. In adaptive bitrate streaming over HLS or DASH, the player decides which rendition to fetch next based on measured bandwidth, and switches at segment boundaries. A pub/sub model, adaptation becomes a question of which tracks a subscriber chooses to subscribe to and how the network prioritises objects within them — the IETF working group explicitly includes rate-adaptation strategies and cache-friendly mechanisms in scope. In practice this is one of the areas still being actively worked out, and it’s a good example of why MoQ is promising but not yet settled: the architecture supports better adaptation in principle, while the standard behaviour is still converging.

MoQ vs WebRTC vs HLS/DASH

MoQ is best understood by what it sits between, so it’s worth being precise about both comparisons rather than treating it as a universal replacement.

MoQ vs WebRTC

WebRTC remains the right tool when the experience is genuinely conversational or the responsiveness requirement is existential — video calls, telehealth consultations, live auctions, interactive betting, remote operation. It’s purpose-built for real-time two-way communication and nothing beats it there at production scale today.

MoQ targets a different shape of problem: one-to-many distribution where sub-second latency matters but full conversational interactivity does not — a concert, a sports broadcast, or a large live event where you want everyone in sync but viewers aren’t talking back. Some vendors already use both, running WebRTC for browser-based ingest and MoQ for large-scale delivery to a global audience.

MoQ vs HLS and DASH

The comparison here is about latency versus incumbency. HLS and DASH are deeply embedded in today’s CDN and player ecosystems, which is exactly why they dominate at scale — and their low-latency variants have improved substantially. But in real deployments, LL-HLS and LL-DASH generally operate in roughly the two-to-six-second range rather than reliably under a second. MoQ aims at sub-second delivery with CDN-style fan-out, which is a different target rather than another flavour of chunked HTTP streaming.

At a glance:

How Production-Ready Is MoQ?

This is where honesty matters more than enthusiasm, because the gap between demo and default infrastructure is where streaming projects get hurt. MoQ has real momentum — and real gaps.

What’s genuinely happening

MoQ has moved well past being a paper specification. The MoQ transport draft is active at the IETF and progressing through revisions, with editors from major technology companies. Interoperability between independent implementations has already been demonstrated, and by NAB 2026, MoQ was visible across the show floor, with multiple encoder, player, cloud, and CDN vendors showcasing interoperable workflows.

Those demonstrations included live playback where one vendor’s encoder published into another vendor’s relay network for delivery to players worldwide. At least one vendor has run MoQ in production since 2025 and reports live deployments reaching the low hundreds of thousands of concurrent viewers. The IETF’s own MoQ overview describes it as a delivery solution with the potential to change how live streaming, collaboration, and gaming media are sent and received.

What isn’t there yet

Set against that, the caveats are substantial and worth taking seriously:

• No final RFC. MoQ is still a draft. Wire behaviour can still change, and features are actively being refined in working-group discussion.
• Draft fragmentation. Implementations target different draft revisions, which are not necessarily compatible with each other. Coordinated upgrades will be needed as the spec settles.
• No native browser stack. Although WebTransport and HTTP/3 are available in mainstream browsers, there is no built-in MoQ implementation — playback depends on JavaScript libraries and custom players.
• Immature surrounding ecosystem. Ad insertion, DRM, complex rights workflows, and standardised telemetry are still being prototyped for MoQ, and don’t approach the maturity of the equivalent HLS, DASH, or WebRTC tooling.
• Thin public performance data. Sub-second results appear in vendor demos and early lab work, but there isn’t yet broad published performance evidence at global scale across diverse networks — unlike the years of real-world data behind existing protocols.

A fair summary for right now: MoQ is feature-complete enough for demos and targeted production deployments, but it is not yet boring, default infrastructure — and “boring” is the bar any protocol must clear before it carries your core revenue stream. The sensible posture is to treat this as the year to test MoQ seriously rather than to migrate to it, keep your architecture modular so a new transport can sit alongside SRT and WebRTC, and keep your fallback paths conventional.

What MoQ Would Mean for Delivery

If MoQ matures as its backers expect, the operational implications for anyone running live infrastructure are significant. Collapsing contribution and distribution into one protocol removes a repackaging origin from the pipeline, which removes both latency and a failure point. Relay-based fan-out with object caching maps naturally onto existing edge footprints, which is why CDNs are among the most active participants. And because objects are immutable and cacheable, the efficiency logic that makes HTTP CDNs work would extend to sub-second delivery instead of being traded away for it.

None of that removes the fundamentals. Glass-to-glass latency will still be shaped by encoding, throughput and network conditions, player buffering behaviour, and how close your edge sits to the viewer — a faster transport doesn’t rescue a poorly tuned pipeline. If you’re running live sports or large live events today, the practical wins are still in the existing toolkit: efficient contribution over SRT, well-tuned low-latency packaging, and edge delivery close to your audience.

That’s where we’d suggest putting your attention now. 5centsCDN’s live streaming stack covers SRT contribution and live transcoding with global edge delivery, and we work with teams planning large live events where latency and scale both matter. If you’re mapping out a low-latency roadmap and want to understand what’s achievable today versus what to keep an eye on, talk to our team.

Frequently Asked Questions