MoQ, Media over QUIC, is a protocol stack under standardization for delivering live media over QUIC, designed for very low latency and real‑time behavior.
MoQ does not reinvent video delivery from scratch. Instead, it builds on concepts the industry already knows well from RTP/RTSP and realtime communication systems, and adapts them to modern transport and web environments. In that sense, MoQ is closer in spirit to realtime media delivery than to traditional HTTP-based streaming.
By running on top of QUIC, MoQ avoids some of the fundamental limitations of TCP, such as head-of-line blocking. It does not rely on segment-based adaptive bitrate streaming. Instead, it enables image or frame-level delivery, making it more reactive by design. MoQ also standardizes a publish/subscribe control model, which can serve both conversational applications (video conferencing) and largescale real-time streaming.
The interest in MoQ comes from the combination of these elements. Together, they offer a delivery approach that is more responsive, less sensitive to congestion, and better aligned with real-time media requirements than existing streaming stacks, assuming broad adoption across the ecosystem.
Rather than forcing a disruptive replacement of current technologies, Broadpeak favors the convergence. Our approach provides a common foundation for conversational video and real-time streaming, with a transition path that can coexist with today’s streaming infrastructures.
How Adaptive Bitrate (ABR) Streaming Works
In a typical OTT live streaming workflow, cameras capture an event and feed an encoder. The encoded stream is sent to a live streaming platform and distributed through a CDN (Content Delivery Network). Viewers then use a player, often in a web browser or app, to request the stream from the nearest CDN server.
To handle varying network conditions on the viewer side, the video is segmented into short chunk files at multiple bitrates. This allows the player to switch between qualities based on available bandwidth and device performance.
Once created, these segments are packaged, cached across the CDN, and delivered over standard network infrastructure. The player downloads the segments, reassembles them, and plays them back in sequence.
This model scales extremely well and made global live streaming possible. But it also introduces structural latency and buffering. Players must buffer (store in advance) segments before playback, late data is still delivered and decoded, and “live” becomes a moving point rather than a truly shared moment. The system prioritizes robustness and reach, not immediacy.
This trade‑off is precisely where MoQ takes a different approach.
Media over QUIC (MoQ)?
Media over QUIC (MoQ) is a real‑time, low‑latency media delivery protocol under standardization at the IETF. It is designed primarily for the distribution of live media, with a focus on responsiveness and real‑time behavior.
MoQ is built around a publish/subscribe model. A client subscribes to one or more media tracks, and the publisher makes the corresponding media objects available as they are produced. This push-oriented delivery model is not new, it is a foundational concept in RTP/RTSP and WebRTC systems, but MoQ aims to standardize it on top of modern transport mechanisms.
The goal is to provide a common, open protocol stack that can serve both conversational applications and real‑time streaming use cases, reducing fragmentation between historically separate ecosystems and enabling more consistent deployment across networks and platforms.
How live video delivery works with MoQ?
With MoQ, live video is delivered over the QUIC transport protocol, typically using WebTransport over HTTP/3, rather than over TCP-based HTTP streaming. The encoder sends media as real-time data streams instead of producing segmented files as in HLS or DASH.
Rather than relying on multi-second segments, MoQ transports media at a much finer granularity, closer to frames or small groups of frames. This makes the delivery path more reactive to network changes and better aligned with real-time use cases, where reducing latency matters more than preserving every piece of data.
QUIC runs on top of UDP and avoids head-of-line blocking at the transport level. A delayed or lost packet does not stall the entire delivery pipeline, as can happen with TCP. That said, there is no magic: packet loss can still occur in network devices or endpoint buffers, especially under congestion. When lost data is not recovered in time, it may result in visual impairment. On the player side, this is often handled through error concealment techniques, such as repeating the last correctly decoded frame, which can appear as a brief video freeze, but without adding extra latency.
QUIC also includes acknowledgment mechanisms and congestion control, similar in principle to TCP. The key difference is that these mechanisms are implemented at the application level rather than deep inside the operating system’s TCP stack. This gives applications more control over how media streams behave, especially when QUIC-based streaming sessions coexist with traditional TCP traffic. In practice, this makes it easier to optimize realtime video delivery under mixed network conditions.
Importantly, MoQ is not positioned as a guaranteed replacement for adaptive bitrate streaming. Its strengths are most evident in scenarios that require very low latency and real-time interaction, such as live betting, gaming, auctions, or certain sports use cases. For more traditional streaming scenarios, ABR-based delivery remains highly effective.
This is why, instead of assuming a full shift from HAS (HTTP Adaptive Streaming) to MoQ, Broadpeak focuses on transition paths. The goal is to allow MoQ and ABR streaming to coexist, potentially for a long time, using existing infrastructure, hardware, and workflows. This makes it possible to move smoothly in one direction or the other, depending on adoption, use cases, and operational constraints, without forcing a binary choice.
How to Move Large-Scale Live Events to MoQ?
The video community has already started to experiment with end-to-end MoQ, often comparing it with traditional HTTP adaptive streaming. However, most of these experiments focus on greenfield setups and say little about how MoQ fits into existing streaming infrastructures.
Instead of rebuilding the full delivery chain, our exploration team took a pragmatic path. We looked at MoQ from the player side. The question we wanted to answer was simple: How can transition large-scale live events to MoQ be made without breaking what already works?
Our approach relies on a proven HAS infrastructure and adds a lightweight HAS-to-MoQ relay at the cache level. Think of it as a “half MoQ relay” setup. The same content feeds both HAS and MoQ flows, from the same cache.
This setup made it possible to validate two aspects:
- Cache behavior when serving both HAS and MoQ flows simultaneously
- Measured impact on:
- Server-side CPU consumption
- Client-side quality of experience
We also explored the use of WebTransport over HTTP/2 within this architecture. This work is still ongoing, but initial results suggest it is a viable option.
Early findings were presented at Mile High Video in Denver earlier this year, where they generated constructive feedback and interest from peers in the streaming community.
We measured performance, identified challenges, and tested ways to mitigate them. The results and mitigation strategies identified during this work will be detailed in an upcoming white paper, which documents the experiments and their results in depth
Use code NS8355 to register for a free Exhibits Pass.
