We've been live streaming video at Bambuser since 2007, and we try to stay at the forefront of streaming technology with our customers' use cases always in mind. One protocol we've been watching closely is MoQ — Media over QUIC — a candidate for what might come after today's HLS and DASH. Here's where it stands, and what it could change.
In the early days, we handled the scaling of video distribution with a network of relay servers, capable of relaying and scaling distribution to tens of thousands of viewers. Video reached viewers over progressive HTTP for Flash players, and through fragmented MP4 in WebSockets. That gave us very low latency, but the setup had its drawbacks too.
Later on, both Bambuser and the industry in general, have settled on segmented formats, primarily HLS but also DASH, as the common protocols. This allows much easier scaling to essentially infinite audience sizes, allowing using any off the shelf CDN for distribution. It also allows other niceties such as smooth, gapless switching between different quality levels to adapt to viewer network capacity.
HLS and other segmented formats come with one major compromise though - latency. Whereas one normally would view live streams with an end-to-end latency of 1-2 seconds in the old setup, the lowest you get with segmented formats is around 6-10 seconds. With some tweaks on top (our custom low latency HLS extensions, or with Apple’s standard low latency HLS), it is possible to get down to the level of 2-3 seconds again though.
One of the reasons of HLS becoming such an entrenched standard is because of Apple, because of what they allow and don’t allow.
On iOS in Safari (and up to recently, in any browser on the platform), the only form of live video streaming that was possible in the browser was Apple’s HLS. On other browsers, developers were free to inject their own streamed video content for playback, using the Media Source Extensions API, commonly abbreviated MSE. Apple does support this in Safari on desktops, but for the longest time, it wasn’t allowed on Safari on iOS. Hence, if you wanted live streamed video there, HLS was the only option. (At a much later time, WebRTC was also supported - but delivering streamed video over WebRTC comes with a different set of challenges.) Since the last couple of years (since iOS 17.1), this restriction has finally been lifted though, so now it is possible to do streaming through other protocols in Safari as well.
The MoQ protocol
The MoQ, Media over QUIC, protocol is developed to overcome a number of the limitations in the current streaming landscape.
Currently, different protocols are used for ingest (for sending video from the producer to the streaming platform), and for playback (from the CDN to the viewers). For ingest, protocols such as RTMP and SRT are common, while playback often is done with HLS or DASH. With MoQ, one could potentially use the same protocol for both ingest and playback (although one of course also could mix and match).
As the name indicates, the main innovation in MoQ is being able to use QUIC. This is a new transport layer protocol, replacing TCP. With MoQ, one can send video and audio in different QUIC streams, allowing setting different priorities for each of them. If a packet is lost in the video stream, requiring retransmissions in order to not get a garbled video stream, this doesn’t need to block the audio stream.
Another innovation in QUIC is that the same connection can stay active while migrating across networks, e.g. between mobile networks and wifi. (This isn’t an issue with HLS, where every segment is fetched in a separate HTTP request, but it can be an issue for the producer of the video stream. Although, practically, for a properly produced live show, we recommend staying on one single stable network.)
Streaming with MoQ happens over an established connection, contrary to HLS/DASH which are stateless, where segments are fetched in small individual requests.
One major limitation is relating to CDNs though. HLS and DASH can be transported through any CDN, without the CDN having to support it explicitly. With MoQ, the CDN does need to explicitly support the protocol. I.e. in one sense, it would be a return to Bambuser’s previous setups with relay server networks.
As the protocol is new (to the point of not being a finished standard but it is still in development), the only major CDN vendor supporting it is Cloudflare. In particular, Amazon Cloudfront does not support it yet (and it is unclear whether it is on their roadmap).
As many earlier format wars have been decided by Apple, through what they support and don’t support, this one might not have to be decided that way. As Apple do allow MSE in Safari these days, it’s possible to do playback of custom protocols in Safari, so Apple’s stance on the topic might not matter at all in the end in this case.
However, in order to use QUIC from within a browser, the WebTransport API has to be used. Current MoQ implementations consider this only to work reliably in Chrome at the moment, so with other browsers, the existing MoQ implementations fall back on WebSocket instead - losing the advantage of QUIC (which was one of the major selling points). This is most probably only a temporary matter though.
Another open question is how well it works in practice for switching between different video qualities, for adapting to different network conditions. The protocol clearly is set up to be able to handle it, but whether the existing implementations support it, and to what level of robustness, is still unclear.
On the other side - for producing live streams, for sending them to the streaming platform, MoQ can also be used. However, at the moment, none of the common streaming applications ship support for it. There are third party plugins that can be added to add this capability, but it’s not available out of the box.
As the MoQ ecosystem in 2026 is very much in its early stages, we’re continuing to follow how it evolves and when the right time comes to bring parts into our platform.
.png)
