What Is Media Over QUIC (MoQ) And Why Are People Talking About It?

Media Over QUIC, or MoQ, is gaining traction as a path toward reliable scalability at ultra-low latencies. Learn about this emerging streaming protocol and how it can suit your video workflow needs.

The video streaming industry has operated within a set of hard tradeoffs: low latency vs massive scale. It’s rare to achieve both with the same architecture, without significant complexity. This fragmented ecosystem has engineering teams stitching together multiple protocols across ingest, packaging, and delivery. Each protocol has its own failure modes, tooling requirements, and operational overhead. For organizations running mission-critical video infrastructure across surveillance, live events, government, and enterprise workflows, this complexity is a direct constraint on what’s architecturally possible.

Here’s what MoQ is, how it works, where it stands today, and why it matters for teams building or evaluating video delivery infrastructure.

What Is Media Over QUIC (MoQ)?

Media over QUIC (MoQ) is a publish/subscribe media delivery protocol being developed as an open standard. In other words, MoQ is an emerging protocol effort aimed at delivering reliable, ultra-low latency streaming at scale. It’s built on top of QUIC (the transport protocol that also powers HTTP/3) and is designed to deliver media at sub-second latency to audiences of any size.  

MoQ aims to provide single protocol for both ingest and distribution. While it is not a finished standard, it represents a serious attempt to rethink how media moves across the internet. Leading organizations are investing and collaborating in its development, including Cloudflare, Akamai, Cisco, Google/YouTube, Meta, Synamedia, and now Wowza.

The Problem: A Protocol Stack Built From Compromises

RTMP handles ingest but doesn’t scale for distribution. HLS and DASH scale beautifully through HTTP CDNs, but introduce latency. WebRTC delivers sub-second interactivity, but can be expensive and difficult to scale beyond small audiences.

Each of these protocols excels in its niche. The problem is that modern video use cases, like sub-second live auctions, interactive broadcasts to large audiences, globally distributed surveillance feeds, and real-time sports broadcasts, increasingly demand low latency and high scale and architectural simplicity. To understand why MoQ exists, it helps to trace how today’s protocol landscape evolved.

Real-Time Messaging Protocol (RTMP)

RTMP emerged in the early 2000s as a breakthrough for live video. Its persistent TCP connection between a Flash client and a media server enabled 2–5 second latency, powering the first generation of live platforms. But that stateful architecture was not built for larger-scale audiences.

For RTMP streaming, every viewer requires a dedicated connection to a specialized media server, and it can’t leverage commodity HTTP CDNs. Plus, head-of-line (HOL) blocking in TCP means a single lost packet could freeze the entire stream. While industry settled on RTMP for the “first mile” ingest from camera to server, it needed something else for distribution.

HTTP Live Streaming (HLS) & Dynamic Adaptive Streaming over HTTP (DASH)

HLS and DASH solved the scale problem by treating video as a sequence of small, static files served over standard HTTP. With HLS and DASH, video could be cached by any CDN and served to millions of concurrent viewers at a reasonable cost. However, the key tradeoff to this scalability is increased latency.

Players need to buffer multiple segments before playback can begin, which creates 15–30 seconds of unavoidable delay baked into the architecture. Developments around Low-Latency HLS (LL-HLS) have pushed this down to the 2–4 second range by layering stateful, real-time behaviors onto a fundamentally stateless protocol. This adds complexity without fully escaping the underlying design constraints.

Web Real-Time Communication (WebRTC)

WebRTC took a different path entirely, optimizing for sub-500ms conversational latency through direct peer-to-peer connections in the browser. It’s the gold standard for video conferencing. But, its peer-to-peer architecture scales quadratically, where the number of connections compounds with every participant.

Server-side topologies like SFUs can work around WebRTC’s scaling problem. But, building and operating an SFU infrastructure at scale is essentially building a private, stateful CDN. It works, but it’s expensive, operationally complex, and not standardized across vendors.

The Solution: How MoQ Solves Latency & Scalability Problems

The current stack forces engineering teams to choose between latency, scalability, and architectural simplicity. MoQ can yield some key benefits for organizations looking to stream ultra-low latency video at scale, without the technical overhead. This is because MoQ is:

1. Built on QUIC , not TCP, enabling faster connection and retransmission times
2. A publish/subscribe model purpose-built for media delivery
3. Organizes media into a clean Tracks/Groups/Objects hierarchy
4. Supports web browsers natively through WebTransport and WebCodecs

MoQ Is Built on QUIC, Providing Stability and Faster Playback Compared to TCP

MoQ’s choice of QUIC as its transport foundation isn’t arbitrary. QUIC aims to address the very structural problems that have plagued TCP-based streaming for years. Traditional HLS, DASH, and LL-HLS workflows send data in chunks, ranging from several hundred milliseconds to several seconds of video data at a time. QUIC, on the other hand, can send data in smaller chunks, often a single frame or a small group of frames. This eases bandwidth congestion and ensures reliable delivery.

TCP can introduce head-of-line (HOL) blocking, where a single lost packet blocks delivery of everything behind it. Even if the blocked data belongs to a completely different media track, this still is a performance bottleneck. QUIC, on the other hand, multiplexes independent streams within a single connection. Each stream can have a custom-set priority. For example, a 911 emergency response platform could prioritize audio capture. That way, a lost packet on the video stream doesn’t stall audio delivery (or vice versa). This eliminates the stuttering and latency spikes found in RTMP and HLS.

When a device switches from Wi-Fi to cellular, QUIC migrates the connection without interruption. This eliminates rebuffering and reconnection handshakes that can cause issues. QUIC’s 0-RTT resumption also means returning viewers can begin playback almost instantly, without the multi-round-trip handshake overhead of TCP and TLS. Finally, all QUIC connections are encrypted with TLS 1.3 by default. All this amounts to QUIC providing a more reliable, lower-latency experience for all viewers.

MoQ Provides A Streamlined Publish/Subscribe Model for Media Delivery

MoQ’s real innovation is in its application-layer design. Its publish/subscribe model is purpose-built for media delivery. There’s no protocol boundary between contribution and distribution with MoQ. It is a single protocol that covers ingest from cameras through delivery to end viewers. This eliminates the repackaging step where RTMP gets converted to HLS/DASH at the origin. That said, most teams may still use RTMP, SRT, or RTSP for ingest.

Instead of the stateful session management of WebRTC or the file-based chunking of HLS, MoQ lets publishers designate media tracks that subscribers can request by name. A publisher might announce tracks for each video rendition, like video-1080p, video-720p, and audio-english. That way, subscribers can choose which tracks they want, and a network of relays distributes those specific tracks to the viewer.

An MoQ relay forwards immutable objects without parsing, transcoding, or repackaging the content. The relays manage the subscriptions and cache the delivered objects when possible. The client request is served from the relay and does not have to go back the origin packager. Relays forward object payloads without parsing or modifying media content, reading and acting on object metadata for routing, caching, and priority decisions. This caching is critical to how MoQ relays help provide reliable scalability.

Relays don’t need to understand the media. This makes relay infrastructure far simpler and cheaper to operate than the equivalent WebRTC SFU or HLS origin/packager chain. Fan-out is also built into MoQ. One upstream subscription from a relay to a publisher can serve thousands of downstream subscribers. This is how MoQ achieves CDN-like scale without CDN-like complexity.

MoQ Structures the Data Model into Tracks, Groups, and Objects

MoQ organizes media into a clean hierarchy:

• Tracks are named streams of media (including video, audio, metadata, captions, and even non-media data like chat or game state).
• Groups are independently decodable units within a track. For video, a group typically corresponds to a GOP (Group of Pictures) beginning with a keyframe.
• Subgroups are subdivisions within a Group that map directly to the underlying QUIC streams. All Objects within the same Subgroup are generally sent on the same QUIC stream, guaranteeing delivery order. Numbering subgroups is an opportunity to prioritize encoding, with lower-numbered Subgroups considered higher priority.
• Objects are the individual units sent on the wire, each belonging to a track and positioned within a group. Every Object within a Group belongs to exactly one Subgroup or Datagram.

This structure enables several capabilities that are difficult or impossible with current protocols:

• New subscribers can join mid-stream at group boundaries
• Relays can cache and forward objects without media-aware logic
• Publishers can define priority levels so that under congestion, the relay drops low-priority data (like a lower-quality video layer) rather than stalling everything

MoQ Is Browser-Native via WebTransport

WebRTC has had native browser support across Chrome, Firefox, Safari, and Edge for over a decade, which is one of its strongest advantages. But WebRTC’s browser implementation is a tightly coupled stack that gives developers limited control over the media pipeline.

MoQ takes a different approach through WebTransport, the W3C API that exposes QUIC’s multiplexed streams and datagrams directly to browser applications. MoQ’s simpler client-server architecture reduces setup overhead and improves time-to-first-frame. For non-browser environments, MoQ can run directly over raw QUIC. With WebCodecs for encoding and decoding, developers can maintain granular control over the media pipeline rather than working within WebRTC’s guardrails. MoQ can also use Media Source Extensions (MSEs) if the objects are CMAF-compliant.

Limitations Of The Current Media Over QUIC (MoQ) Protocol

MoQ is promising, but it’s important to be clear-eyed about where it stands today. There are some gaps that are inevitable with a less mature protocol like MoQ. These are real constraints. They’re also the kinds of constraints that characterize every significant protocol transition in its early stages. For example, HTTP/3 and QUIC itself went through a similar trajectory before reaching broad adoption. Engineers evaluating this technology for their workflows should understand these realities.

MoQ Is Still Being Standardized and Developed

The core MoQ Transport (MOQT) specification is still being developed by the IETF. The protocol is evolving, and breaking changes between draft versions are expected. Production deployments today are effectively early-adopter implementations pinned to specific draft versions.

Major companies like Cloudflare, Akamai, and Wowza have working implementations, but interoperability testing is ongoing and the tooling ecosystem (encoders, players, relay software, analytics) is still maturing. OBS has initial MoQ support through community efforts, but there is minimal hardware encoder support.

WebRTC Is More Mature Than MoQ

WebTransport is available in Chromium-based browsers and Firefox. As of April 2026, it is now also supported in Safari and iOS26.4. This is meaningful for consumer-facing delivery that requires fallback mechanisms (typically WebSocket/MSE or HLS) to maintain universal coverage. As WebTransport support broadens, MoQ’s browser story will strengthen. But, teams evaluating MoQ today should plan for hybrid delivery paths.

For true peer-to-peer, bidirectional communication where sub-250ms latency is non-negotiable, WebRTC remains a more mature choice. MoQ’s client-server, publish/subscribe architecture is designed more for scalable one-to-many and few-to-many distribution with sub-second latency. That said, there is potential that MoQ for video conferencing could compete with WebRTC-powered applications.

WebRTC has benefited from over a decade of production tuning on bandwidth estimation algorithms like GCC. Each algorithm involves tradeoffs that latency-sensitive applications must carefully consider. MoQ relies on QUIC’s pluggable congestion controllers to monitor bandwidth, RTT (Round Trip Time), and packet loss. This allows for rapid detection of network congestion, allowing the encoder to adapt its bitrate accordingly.

Real-World Use Cases and Applications for MoQ

Despite its emerging status, MoQ’s architecture maps cleanly to several high-value use cases that are poorly served by today’s protocol options:

1. Live Sports & Events At Scale
   Stream with sub-second latency to audiences of thousands or millions. Employ adaptive bitrate switching and synchronize video with real-time data overlays (scores, odds, statistics). HLS is too slow and WebRTC is too expensive to scale.
2. Interactive Streaming
   Support live auctions, betting, live commerce, and audience participation formats where the latency between action and viewer response directly impacts business outcomes.
3. Surveillance & Monitoring
   DOTs, public safety groups, and enterprise security operations teams need to move video efficiently across WAN links. MoQ’s relay architecture and track-based model simplify the delivery of multi-camera, multi-resolution feeds across distributed monitoring infrastructure.
4. Unified Live & VOD Workflows
   Unify live and on-demand playback capabilities under a single protocol. MoQ’s data model supports live streaming as well as time-shifted playback, DVR-style scrubbing, and on-demand retrieval of past objects. Avoid switching between WebRTC or RTMP for live and HLS for VOD.
5. CDN Middle-Mile Optimization
   Reduce middle-mile latency and improve resilience on unreliable network paths. QUIC-based transport can improve origin-to-edge delivery within CDN infrastructure before MoQ reaches end viewers.

Wowza Joins The OpenMOQ Consortium

The OpenMOQ Software Consortium is an industry-led initiative focused on advancing MoQ through high-performance, open-source software. The work spans relay implementations, player development, interoperability testing, and the practical engineering required to move an RFC toward commercial reality.

Wowza is proud to be a member of OpenMOQ,and our involvement reflects a deliberate strategic commitment to defining this spec, not a speculative bet on whether it will be adopted. As a member of OpenMOQ, Wowza brings deep ingest, transcoding, and packaging capabilities across on-premises, cloud, edge, and hybrid ecosystems. These are the stages of the media pipeline where protocol transitions create the most complexity, and where the implementation determines whether a new protocol can actually work in production.

MoQ is not replacing RTMP, SRT, HLS, WebRTC, or any of the protocols our customers rely on today. These remain essential, battle-tested tools for specific workflows, and Wowza will continue to support them. But, MoQ represents a promising path toward unified, modern media transport. Wowza is at the table helping shape how that gets built.

We look forward to collaborating with the OpenMOQ community to advance open, interoperable approaches for streaming with MoQ. If you’re ready to learn more, contact us today.

Media Over QUIC (MoQ) FAQs:

Does MoQ require a CDN?

MoQ doesn’t strictly require a CDN, but its architecture is purpose-built to take full advantage of one. The relay-based publish/subscribe model lets intermediate servers subscribe to media tracks from upstream, cache them, and fan them out to thousands of downstream viewers simultaneously. These relays can be deployed at CDN edge nodes, within 5G networks, or even on local Wi-Fi routers. Placing media copies closer to end users cuts latency and speeds up error recovery. You can run MoQ without a CDN by connecting directly or through a single relay. But for live streaming at scale, a distributed relay network is what unlocks MoQ’s scalability with sub-second latency.

How does MoQ handle congestion and packet loss?

MoQ inherits QUIC’s native congestion control and loss-recovery mechanisms, then layers media-aware intelligence on top. The MoQ Transport specification (MOQT) intentionally does not mandate a single congestion control algorithm. Instead, it gives application developers flexibility to choose or implement controllers suited to real-time media.

Because QUIC multiplexes independent streams, a lost packet on one stream (say, an audio track) doesn’t block delivery of another (like the video track). MOQT also supports stream prioritization, so under congestion a relay can drop or delay lower-priority data (like a secondary video quality layer) while protecting the primary feed. When a viewer falls behind the live edge, the relay can cancel unsent older data and prioritize the newest content, helping viewers catch up quickly.

Can MoQ be used for both live and on-demand streaming?

Yes. One of MoQ’s core design goals is to unify real-time, low-latency, and on-demand delivery under a single publish/subscribe protocol running over QUIC. Traditional streaming stacks force you to choose between low-latency protocols (like WebRTC) and scalable delivery protocols (like HLS/DASH), often requiring entirely different infrastructure for each. For live streaming, MoQ excels at sub-second delivery at massive scale thanks to its relay architecture. For on-demand content, the same publish/subscribe model lets viewers subscribe to pre-published tracks and receive them through the same relay infrastructure. This means one protocol, one set of servers, and one client implementation can cover use cases ranging from interactive live broadcasts to VOD playback.

Does MoQ support adaptive bitrate streaming (ABR)?

MoQ supports adaptive bitrate playback, but it approaches ABR differently than segment-based protocols like HLS or DASH. Rather than switching between pre-packaged segments at different quality levels, MoQ enables track-level switching. A publisher can offer the same content as multiple parallel tracks at different bitrates, and the subscriber (or relay) selects which tracks to receive based on available bandwidth.

When network conditions change, the client or relay can add or drop tracks accordingly. MoQ also supports network-assisted bandwidth estimation mechanisms that provide receivers with hints for making smarter track-selection decisions. The result is adaptive quality that responds to real-time network conditions at a more granular level than traditional segment-based ABR.

What transport protocols does MoQ use?

MoQ runs on QUIC, the UDP-based transport protocol that also powers HTTP/3. Specifically, MoQ Transport (MOQT) can operate directly over raw QUIC for native applications (server-to-server communication, native mobile or desktop apps), or over WebTransport for browser-based deployments. WebTransport is a web API built on top of QUIC that gives browser applications access to QUIC’s features, and it is now supported across all major browsers.

Both transport modes give MoQ access to independent multiplexed streams (no head-of-line blocking), built-in TLS 1.3 encryption, connection migration (seamless handoff when a device switches from Wi-Fi to cellular), 0-RTT connection establishment for faster startup, and support for both reliable streams and unreliable datagrams. All media transported via MoQ is encrypted at the transport layer by default. MoQ also supports end-to-end encryption where relay servers can forward media and access metadata for caching decisions without being able to decrypt the actual content.