Nobody Is Rebuilding for MoQ

Media over QUIC is usually explained as a replacement architecture. Segments give way to objects, request/response gives way to publish/subscribe, and the delivery model is rebuilt around a relay tree. That is a fair description of the protocol.

It is not a description of a single shipping product.

We went through the commercial MoQ implementations one at a time for our ecosystem directory and product listing, reading vendor documentation rather than press coverage. The same shape turned up in every one of them, and it is not the shape the protocol’s own framing suggests:

MoQ is being sold as a final delivery hop bolted onto an unchanged upstream.

Not one vendor is asking anyone to rebuild. That fact deserves more attention than any latency figure, because it determines which parts of the specification will matter commercially — and which of MoQ’s advantages most deployments are quietly giving up.

The evidence

Taken individually, each of these reads as a sensible product decision. Taken together they are a pattern.

Red5 states the strategy outright: their MoQ beta is designed to let enterprises deploy MoQ while preserving investments in current hardware, encoders, cameras, and contribution protocols. Streams arrive over WebRTC, WHIP, SRT, RTMP, RTSP, or Zixi, and a component called the Video Packager converts them to MoQ on the way out. Six legacy ingest protocols, one new egress.

Wowza’s proof-of-concept module maps the CMAF fMP4 that Streaming Engine already produces onto MoQT via the CMSF mapping — explicitly without modifying any core code. The entire contribution is an output adapter.

Ant Media ships MoQ as an installable plugin. Once a stream is in, their documentation notes that recording, the REST API, and adaptive bitrate all work as normal. The AMS pipeline is untouched; MoQ is a new way out of it.

Oracle Video @ Edge accepts traditional feeds — HLS over CMAF, SRT — and converts at the edge, with conversion back to CMAF/HLS for backwards compatibility on the far side. MoQ in the middle, familiar formats at both ends.

nanocosmos enabled MoQ in their H5Live player as a default-on setting with automatic WebSocket fallback. For an existing customer, adopting MoQ was closer to a configuration change than a migration — which is precisely why they were able to accumulate twelve months of production data across six regions while everyone else was still demoing.

Broadpeak says it in as many words: rather than forcing a disruptive replacement, they favour convergence, with a transition path that coexists with today’s infrastructure. Ateme feeds its existing real-time encoding into someone else’s relay fabric.

Vindral is the most instructive case, because their marketing and their architecture section say subtly different things on the same page. The headline is full end-to-end MoQ support. The architecture text says the implementation bridges MoQ with established delivery paths — RTMP, MPEG-TS, SDI, and their own stack — and that MoQ enhances performance without changing what already works.

Both statements are true, and the gap between them is the whole point of this post. MoQ runs end to end inside Vindral’s platform, and it is bridged to conventional formats at the contribution edge. When a vendor who has been shipping MoQ since 2023 still lists SDI as an ingest path, the pattern is not caution. It is the market.

Nomad Media put it almost verbatim at NAB: their MoQ player and relay ingest live content from RTMP, RTSP, SRT, Zixi, WebRTC, HLS, and Low-Latency HLS, and the stated point of demonstrating that was to show broadcasters they can adopt MoQ without disrupting existing operations. Seven legacy ingest protocols, one new egress. The same sentence, again.

The one commercial exception is Quicly, which is greenfield — but even there, ingest is SRT, RTMP, and a browser camera. The upstream is still conventional.

Why the shape is this shape

None of this is timidity. It is arithmetic.

The upstream is where the money is. Encoders live in trucks and racks on multi-year refresh cycles. Contribution links are under contract. Camera fleets are capital. A protocol that requires replacing any of that competes against the depreciation schedule, and loses. A protocol that terminates at the last hop competes against nothing — it is a new output on equipment you already own.

This is also why hardware encoder partnerships are a better adoption signal than any latency benchmark. Red5 working with Osprey Video, Videon, and Amino on MoQ hardware encoding is a more meaningful indicator than another sub-second demo, because it is the first sign of the pattern breaking — MoQ moving upstream of the packager rather than sitting downstream of it.

What this predicts about the spec

If the commercial job to be done is “map what I already produce onto MoQ”, then the parts of the specification that decide adoption are not the ones that get the attention.

The container layer matters more than the transport. CMSF, LOC, LOCMAF, and the packaging drafts are the machinery that answers “how do I express my existing media as MoQ objects”. That is the question every one of these vendors had to solve first. It is no accident that the container cluster is the fastest-growing part of the draft pile — and that it kept growing all year while the transport draft worked through the filter rewrite that finally landed in draft-20.

Backwards compatibility is a feature, not a compromise. Oracle converting back to CMAF/HLS at the edge and Synamedia keeping MPEG-2 TS compatibility in B2B distribution are not transitional hacks. They are the product.

A “MoQ-capable” claim tells you very little. It may mean a relay speaking a numbered draft-ietf-moq-transport revision, or one speaking moq-lite — two different wire protocols that do not interoperate. And either way it says nothing about which container format your media is expressed in, which is a separate question with its own competing answers. Both are worth a post of their own.

What a bolt-on deployment gives up

Here is the part that deserves scrutiny, because vendors have no reason to raise it.

MoQ’s headline benefit — lower latency from removing the segment as a unit of delivery — survives being bolted on. Most of its architectural benefits do not, because they need the publisher to participate.

Object granularity is inherited from upstream. This is the big one. If your packager emits CMAF segments and an adapter transmuxes them into MoQ objects, your objects are segment-shaped or chunk-shaped, not frame-shaped. You are running frame-oriented transport over chunk-oriented media. You get QUIC’s loss behaviour and the removal of the request/response round trip, but the encoder still gates when anything can leave. Quicly’s 300 ms GOP is the honest version of this: a floor no transport can undercut.

Subscription-driven features need a cooperating publisher. The most interesting work in the working group right now — Top N Tracks, range and location filters, sender-side track switching — assumes tracks and object properties that a publisher deliberately structures. An adapter that receives an opaque RTMP stream and wraps it has nothing meaningful to filter on. The relay can forward or not forward; it cannot select the three highest-scoring feeds if nobody published a score.

Per-object priority needs someone to set it. The delivery-order machinery we covered in delivery order and priority, including the in-flight work on updatable publisher priority, assumes a publisher expressing what matters. Transmuxed content arrives with priority information already discarded.

None of which makes bolt-on adoption wrong. It is the correct first move, and the latency win is real. But it means a large part of the industry is about to conclude that MoQ is “QUIC transport for live video” — because that is genuinely all they will have deployed — while the working group builds a publish/subscribe media architecture that most deployments are not yet positioned to use.

What native actually looks like

There is one place MoQ runs end to end with nothing bridged, and the number it produces is worth sitting with.

Fraunhofer FOKUS’s FAMIUM MoQ is a research implementation of draft-ietf-moq-transport-16: a WebCodecs client against a moq-rs server. Their demonstration captures Unity game scenes, encodes through FFmpeg, and streams over WebTransport — reporting end-to-end latency below 40 milliseconds.

The commercial figures we track cluster between 250 ms and 700 ms. This is roughly an order of magnitude lower.

It is emphatically not a like-for-like comparison. Synthetic content, a research network, no CDN, no scale requirement — and critically, a game engine that hands over a finished frame the instant it renders, rather than a camera feeding a segmenting encoder. Nobody should quote 40 ms as what MoQ delivers.

But the size of that gap is the argument of this post, stated in a number. When the publisher genuinely produces MoQ objects at frame granularity, the transport is nowhere near the bottleneck. The seconds in a production stack are upstream of the protocol, in exactly the equipment every vendor has committed to not touching.

That is also why the interactive and synthetic-media cases — game engines, Unreal and Unity, agent-driven media — may end up demonstrating what MoQ can do before broadcast does. They have no legacy contribution chain to preserve.

Questions worth asking a vendor

1. Where does MoQ start in your pipeline? At the encoder, or at the last hop?
2. What is the object granularity? Frame, chunk, or segment — and what sets it?
3. What is the GOP length in the path you are selling me? That is your latency floor.
4. Can a subscriber select tracks by a property my publisher sets? If not, you have transport, not publish/subscribe.
5. Which transport — draft-ietf-moq-transport or moq-lite? Those are two different wire protocols and they do not interoperate. Then, separately: which container format — CMSF, LOC, LOCMAF? That one is negotiable; the transport is not.
6. What happens to priority information from my source?

The upshot

The commercial ecosystem has found the version of MoQ that can be sold today, and it is a good version: better loss behaviour, no segment round trips, and no capital expenditure. Expect that to be most of what ships for the next couple of years.

The gap worth watching is between that and what the protocol is being designed to do. It closes when MoQ moves upstream of the packager — which is why those encoder partnerships, not the benchmarks, are the thing to watch.

We track which stack each product is actually on, and where MoQ sits in its pipeline, in Built with MoQ and the ecosystem directory.