Media Over QUIC (MOQ): How it will redefine realtime media and streaming

Learn about MOQ and its emergence in the media industry. See how it compares to traditional WebRTC technologies.

MOQ. Media Over QUIC. A new standard specification that is becoming quite popular, assuming you trust the many blog posts and YouTube videos floating around about it lately.

What exactly is MOQ, and how will it redefine realtime media and streaming?

This is exactly what I want to try and cover in this article.

As with many of the things I do, I’ll be doing this from the perspective of someone who’s been focused on WebRTC technologies for over a decade now…

Everyone is now talking about MOQ

Looking at my RSS feed for recent months, it seems like people start talking about MOQ in my industry just as much as they do talking about WebRTC.

Here are a few of the posts I’ve read recently on this:

• nancosmos upgrades their service to use MOQ – they even explain why
• Cloudflares comes out with a MOQ beta, which I covered in my previous article focused on Cloudflare
• Red5 takes the stance of MOQ and WebRTC can live together, which is obvious, considering they offer multi-protocols streaming servers
• Tony Hicks shares his thoughts on MOQ standardization, which is a great insightful read
• Lorenzo toying around with MOQ implementation in Janus – giving us a glimpse on some of the technical challenges
• Luke Curley left Discord for MOQ

If I missed your banter online – feel free to add your post link in the comments below 😉

What is MOQ

If I had to define MOQ, and it seems like I do, I’d say this:

MOQ is a network protocol suitable for web media streaming, covering both live and on demand scenarios.

It does so while taking into account the modern Internet’s infrastructure and network behavior.

Now that we know what it is (🤣) lets dive a level or two deeper.

MOQ relies on QUIC (or HTTP/3 or WebTransport) for its transport layer. Unlike most other realtime media delivery protocols, MOQ doesn’t use RTP. This makes it quite different in the network protocols scenery that we have today.

The three main characteristics in MOQ that I find unique?

1. A clear definition of a server component – the RELAY – which is something that can be “easily” introduced by existing CDN vendors
2. Support for both live and on-demand scenarios
3. Piggybacking on HTTP/3, making it transparent to firewalls, NATs and other nasty network policy components

There is a lot more in terms of technical advantages to MOQ and QUIC than what I plan on sharing in this article. Suffice to say that it has solutions for many of the nerdy problems previous technologies and protocols have/had. For now, what I shared here should be good enough.

Latency vs Complexity and the MOQ solution

I already said that MOQ is suitable for both live and on-demand scenarios. If I’ll add it to an older latency diagram that I have, it will likely be something like this:

MOQ fits all latency requirements for streaming protocols, which makes it kinda unique in that regard. As the saying goes:

One MOQ protocol to rule them all, one MOQ protocol to find them, one MOQ protocol to bring them all and in the darkness bind them

The fact that MOQ can do everything in a simple and scalable fashion means that it is going to be quite complex to get it to work properly. Why? Because if we have one protocol to rule them all, then it needs to do many things that are sometimes opposite to each other – be able to buffer and delay while being able to playback really really quickly for example.

To me, this indicates that we’re ways to go from a solid implementation across browsers and devices that is useful for all use cases without nasty bugs and headaches. That said, I wouldn’t pass on MOQ because of that – just be cautious about it.

Oh – and as always, the rule applies – the lower the latency you’re aiming for – the higher the complexity of your service – MOQ included…

Current state of MOQ and the market

We can view the market from two different angles: deployments and announcements.

On the deployment side, we’re far from seeing anything of real relevance yet. Philipp Hancke wrote about it here: we’re simply below 0.0x% of web pages using WebTransport (which is needed for MOQ)…

In a way, it feels like this is 2013 and the technology is called WebRTC. Wait a few years and things will definitely change for the better.

On the announcement side, we’ve seen earlier the waking up that is taking place. For the time being, it is mostly companies showcasing what it is they are working on in order to test the waters and get feedback. Experimenting and figuring out the boundaries of the technology today and from there deducing the most appropriate product/MVP to come out with at some future point.

Hey – we even have OpenMOQ – a software consortium with open source MOQ technology, being created by Akamai, CDN77, Cisco, Synamedia and YouTube.

Most are CDNs or video streaming vendors. Cisco? In the conferencing business (and switches) – more on conferencing later.

The standard itself? Close to ready we’re told. With WebRTC close to ready took a few years. Hopefully, here we will see an RFC by 2026.

MOQ in Streaming

Streaming is where MOQ truly shines. For all intent and purposes, MOQ is built and designed for unidirectional streams (it does bidirectional, but not that well – see below about conferencing). It has two separate message types that distinguish between live and on demand for it – you can FETCH older media or SUBSCRIBE to live media – or you can do both.

The purpose of all this is to be able to cater for both the low latency and higher latency requirements and in a way that can also manage and optimize the quality of service accordingly (in low latency it is often useful to sacrifice some quality to keep pace with the media stream).

To be frank? Streaming is what MOQ is designed for. You’ve got all the goodness of what HLS gives you with low latency capabilities that are usually reserved to WebRTC and similar protocols. The way this is achieved is by having these two separate ”modes” of operation that are specified in the protocol and letting the higher abstraction layers (signaling and application) to figure out what they want exactly and pick and choose the specific messages they’ll use based on their latency requirements.

MOQ plays nice with CDN networks by defining relay entities that relay the traffic over QUIC or HTTP/3 – using HTTP/3 as the mechanism translates to the ability of upgrading existing CDNs by adding HTTP/3 to them and a bit more logic on top instead of replacing them with totally new servers and technologies. This is why the likes of Akamai and YouTube are on the bandwagon of MOQ – it allows them to use existing architectures and upgrade them instead of replacing them.

Another aspect of MOQ that is specific to streaming is the fact that publishers and subscribers use the same protocol – MOQ. They don’t need to use different ingest and viewing mechanisms (no one really ingests HLS when creating a media asset for viewing for example). This end-to-end nature of MOQ is also rather useful in simplifying future architecture of streaming infrastructure.

So what do we have as advantages of MOQ in streaming?

• Live/low latency and on demand out of the box support
• Reliance of classic CDN technology for delivery at scale
• Single protocol for publishers and subscribers

While we see WebRTC used for live streaming, I foresee the migration to MOQ for such use cases once MOQ will mature a bit. Give it a couple of years and we’re likely there.

MOQ in Conferencing

This is where things can get a bit trickier and murkier.

MOQ in the browser relies on having an implementation of QUIC, WebTransport, WebCodecs and WebAudio. You need to orchestrate all these when creating a MOQ player in your browser.

The problem of doing this for conferencing is that there’s a lot that is left for the developers to fill in and that’s when there’s a solution already – WebRTC.

What’s missing? A lot of the nuances of how you get things done with FEC, retransmissions, comfort noise generation, etc. You can develop all these on top of WebCodecs and stitch it into your MOQ-based application, but that’s going to do a lot of work and effort that was already put in place for WebRTC as part of the implementation in the browser – and now you have to do all that in your JS application on top of the browser. It gives you a lot of power, but also a lot of headache and work.

Then there’s the benefits of MOQ relays and traditional CDNs. They no longer apply. Why? Because we need SFUs for group conferencing. Relays are going to be too naive in their implementations, whereas SFUs do a lot of decision making for quality optimizations that there is no other entity this can be delegated to in the world of MOQ (unless you implement a specific type of relay and you might as well call it an SFU while you’re at it).

Two things here to consider:

1. I contemplated the migration to QUIC in WebRTC some 6 years ago. I don’t see this happening – too complicated and not enough interest
2. Zoom tried doing something similar for the web, and ended up in December 2024 just adding support to WebRTC to be done with it. WebTransport+WebCodecs just didn’t work well enough for them at the time, in particular on constrained mobile devices. It might be better now, but I am not sure this is the case (yet)

Should you invest in MOQ today

That’s the big question.

If your use case is in streaming, then yes. Definitely. Experiment with it today. Understand the technology. Figure out how to incorporate it into your mid-term roadmap.

Assuming what you do is conferencing, then I’d suggest waiting on the sidelines for now. There are other headaches to deal with that are more pressing than this adventure.

–

On a totally irrelevant, nitpicking issue, have you noticed that there’s still no logo for MOQ?

How can a technology be promoted without a decent logo?