Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
The IETF’s MoQ Transport draft is on its 21th version. According to Michal Hošna of CDN77, who I interviewed in Prague before IBC 2026, the working group has been predicting completion “in six months” for two years. He now hopes for something final by the end of this year. CDN77 expects to launch a public MoQ offering “in a couple of months” after the standard stabilizes.
Why does MoQ matter? It replaces HTTP’s request/response model with publish/subscribe. A player subscribes once, and the CDN pushes media as it arrives. That eliminates the request for every segment and the latency that segment size builds in.
Here are the key points from the conversation.
- Supporting MoQ takes new software, not a new network. CDN77 needs “a completely different software stack” at the edge. Its network is already tuned for low latency, because low latency removes the buffer that hides network problems.
- The rollout starts at the biggest locations. CDN77 plans to begin with bigger PoPs, adding dedicated servers alongside HTTP. It already runs separate edge types for low latency, QUIC and large files, so MoQ becomes one more.
- One protocol runs from ingest to playout. That replaces separate RTMP, SRT, and Zixi ingest stacks, intermediate protocols, and HTTP delivery, along with the separate libraries, deployments and experts each one requires.
- Social media and user-generated content come first. Influencers want real-time interaction with their audiences, and MoQ combines web conferencing with CDN-scale fan-out.
- HLS and DASH stay for latency of five seconds or more. In that range, Hošna says, MoQ “would only bring integration churn.” WebRTC stays for browser conferencing and peer-to-peer, which are still easier to build with WebRTC.
- The pieces are arriving. OBS plugins, FFmpeg pull requests, hardware encoder work, open source browser players, and MoQ demos on ESP32 chips. CMSF carries CMAF unchanged, so DRM and captions come along, and ABR is at parity with HTTP.
You can get the technical specs from the documentation, and technical details from your favorite AI. This is real world MoQ from a CDN that’s building it and making it real and performant for its customers.
Here’s Hošna’s take on when and why MoQ will become relevant. For the record, I interviewed Hošna’s in early September before the 21st version of the spec released. I know he’s on top of it.
| Application | Hošna’s expectation | In his words |
|---|---|---|
| Interactive social and UGC | Early MoQ adopter | “I think it brings the most benefits” |
| Low-latency fan-out now built on WebRTC | Moves to MoQ fairly early | “WebRTC is not made for CDNs” |
| Browser conferencing and peer to peer | Stays on WebRTC for some time | “Direct peer to peer is easier with WebRTC” |
| Streaming at five seconds of latency or more | Stays on HLS and DASH in the near term | “Those things are currently cheap” |
Rather than present the Q&A as a transcript, here’s a heavily quoted narrative from the conversation. Let’s start with the basics.
For those who’d rather watch, here’s the video, and it’s embedded below.
Contents
What MoQ Is
According to Hošna, Media over QUIC (MoQ) is “a family of protocols, a family of stuff, that’s being developed under IETF’s open standards.”
Two layers matter most. The first is MoQ Transport, or MoQT, which is what most people mean when they say MoQ. It sits “much more low level” than WebRTC, HLS, or DASH. “It’s trying to replace or be an alternative to HTTP,” Hošna says.
Market education & validation
Would your product benefit from an independent technical analysis like this?
Our market education and validation service creates and distributes independent benchmarks, clear product explainers, and polished technical interviews. Proof that turns prospects into customers.
Learn how it works →The second layer is the streaming format. “In the MoQ family we also have streaming formats like HLS and DASH,” he explains. “So we have MSF, the MoQ Streaming Format, that’s on a similar level as those.”
How does MoQT move data? Through publish/subscribe. “MoQT, the fundamental protocol, is just a publish/subscribe protocol to transfer data,” Hošna says. Two design choices set it up for large-scale delivery. “The data is addressable. And there’s first-class support for caching relays. So this is what enables you to do this one to many.”
Relays are optional. “The protocol doesn’t require you to have a relay,” Hošna notes. “So you can do one to one. You can do client-server, stuff like that.” That makes MoQ a candidate for interactive one-to-one applications as well as broadcast-style distribution.
How MoQ Differs from HTTP
HTTP works by request and response. “You request some kind of a resource, you get it back, which is great for files,” Hošna says, “but it’s not usually how media works. Media like videos are continuous streams of data.”
HLS and DASH fit media into that model because HTTP CDNs already existed. “We tried to map media onto the HTTP file semantics,” Hošna explains. “So splitting the files into segments, serving them as single files. But this is fundamentally not the way that media actually works.”
When does the mismatch matter? When latency matters. “Until you try to go low latency, it works fine,” he says. In low latency territory, every segment requires the player to request the file and the server to find and send it.
Hošna compares the alternative to turning on a TV. “You want something more like you subscribe to a channel,” he says. “The server just pushes it to your client as fast as possible with low latency. You don’t have to constantly request new segments.”
Built on QUIC
Where does reliability come from? MoQ inherits it from QUIC. “QUIC gives you this layer of reconnects, retries, not losing data,” Hošna says. HTTP traditionally ran on TCP, which ensured “you will receive the correct data in the correct order.” QUIC delivers the same in-order, guaranteed delivery on top of UDP. “Then the world kind of moved to UDP,” he notes. “And MoQ is using this existing technology of QUIC.”
Less Overhead on the Wire
MoQ’s efficiency comes from two sources. The first is encoding. MoQT is a binary protocol, designed to be “very conservative on the wire.”
Hošna places this in a broader shift. “Historically, many internet protocols were text-based protocols because they’re easy to implement,” he says. “But as the internet is getting larger, we are moving more and more to binary protocols, for more effective packing. You are not wasting so much bandwidth on metadata.”
The second source is the subscription model. With HTTP you have some overhead just given the request/response,” Hošna says. “The request is a message you need to send, and every response is some kind of overhead.” MoQ pays that cost once. “You don’t need to make a request every couple of seconds. You just subscribe and you get a hose of data,” Hošna says. “So you are not wasting bandwidth, and you are not wasting latency on this request/response loop.”
Relays and Fan-Out
How does MoQ scale from one sender to thousands of viewers? Through relays (Figure 2). What sets MoQ apart from other pub/sub protocols is how it exposes data to those relays. “The data is addressable in a manner that is visible to the intermediate relays,” Hošna explains. “So the relay can look at the stuff and see there are some stacks of bytes that have an address, and that are guaranteed by the protocol to be immutable. That way the relay can cache those under this address and send them out.”
Hošna calls the idea simple, though many protocols still lack it, often by design. “Often protocols try not to be inspectable by the intermediaries, for security or privacy reasons.”
MoQT builds this visibility into its object model. “We have groups, we have objects that have addresses, locations, under which we can save them to cache so we can serve them later,” Hošna says. The same addresses drive fan-out. “We can fan them out, because we know that this given object ID needs to be delivered to all the clients.”
Where Relays Live
In a traditional HTTP CDN, content moves from the origin through an origin shield to the edge. Where does a MoQ relay fit? “A relay would be both the edge and the origin shield,” Hošna says.
For customers, he suggests thinking of the whole CDN as one relay. “The whole CDN should represent one big relay. It’s actually a network of relays,” he explains. “You push it to the CDN, the CDN behaves as a relay that can cache stuff and send out stuff, and at the edge of that relay, the client gets all this stuff delivered.”
The model mirrors how HTTP CDNs already work. “This is similar to HTTP with edges and origins,” Hošna says. “This is not necessarily a concept in HTTP itself. It’s just that HTTP allows us to build this on top. This is the same with MoQ.” HTTP uses proxies to cache content, and MoQ uses relays. “For MoQT, we call it the relay, but it’s essentially the same.”
One Protocol from Ingest to Playout
MoQ promises one protocol from the encoder to the viewer. Why does that matter? “Because you don’t have to debug and be an expert on multiple protocols,” Hošna says.
Today’s live workflows stack several technologies. “When we have RTMP, SRT, and Zixi on the ingest, then something else in the intermediary, and then something else for delivery, you need to understand each of those protocols and each of those formats,” Hošna explains. Each one brings its own overhead. Operators have to “have experts on each of those things, have separate libraries, and have separate CDNs,” he says. “Or we need to have separate deployments of RTMP ingest servers and delivery servers.”
MoQ collapses that stack. “With MoQ, we can unify all of this and have one protocol. We can all become experts on one,” Hošna says. The payoff is deeper knowledge and better tools. “You have to understand it and have good debug tooling and all of that. That’s what unification brings you.”
He sums up the difference simply. “You can have one thing you understand very well, compared to having five protocols and not knowing how any one of them works.”
Where MoQ Gets Traction First
Where will MoQ deploy first? Hošna points to user-generated content and social media. “That’s the first place we see it as a CDN,” he says. He expects some real-time communication use cases too, but CDN77’s focus is elsewhere. “We are much more into fan-out use cases.”
User-generated content benefits most because MoQ can handle the whole workflow. “You can also solve the ingest part with it, the transfer, and the content delivery part,” Hošna explains. “So even if you need to ingest a video stream from some user, you can use MoQ. You can use the same fleet of edges to ingest the stuff and egress it to the clients.”
Why Social Media Needs Low Latency
“Social media needs interactivity,” Hošna says. “The influencers are talking to their audiences and want quick interactivity, both from a chat perspective and for other features that social networks are trying to do with current technology that’s not great for it.”
He describes one example. “It’s a way for audiences to join their stream, be with them on stream, have a call, and pick audience members and have them dynamically join.” That scenario mixes two workloads. “This is kind of web conferencing, but you need to fan it out to the audience,” Hošna explains. “And MoQ can combine both of those use cases.”
From Proprietary to Standard
Some of this is possible today, but only for the largest platforms. “The big companies that own the media, where you have their application on mobile that pushes to their CDNs and you consume it again in their application, can already do this stuff, because they can do proprietary protocols,” Hošna says. “And they do protocols very similar to MoQ.”
MoQ aims to make that capability available to everyone. “Let’s standardize this. Let’s make it a commodity. Let’s make it something that everybody can build on,” Hošna says. The payoff is one protocol the industry can optimize together, in place of “proprietary, closed protocols that are hard to deploy, expensive to deploy, and expensive to debug.”
Live Sports
What about one-to-many sports streaming? Hošna is less certain about the near term. “It’s very dependent on their latency sensitivity and where the audience is,” he says.
Services that need very low latency have the most to gain. “Once you start going to sub five seconds of latency, and especially sub two seconds, MoQ brings you more stability,” Hošna says. Those services are already paying for low latency. “It’s already expensive to do low latency with HLS and DASH,” he notes, so he expects their migration “won’t be that hard or that expensive.”
Services at conventional latency will likely wait. “When we are talking about five seconds of latency and more, I would expect, at least in the near term, those people stay with HLS and DASH,” Hošna says. “Those things are optimized. Those things are currently cheap, and MoQ currently would only bring integration churn.”
What CDN77 Needs to Support MoQ
HLS and DASH owe much of their success to HTTP. They run on any CDN, at low cost and massive scale. What does a CDN have to change to carry MoQ from ingest through delivery? Hošna splits the answer into software and network.
The software changes are substantial. “We need a completely different software stack,” he says. CDN77 accepts that, because its low-latency customers already expect custom work. “Many of those applications already require customized stacks.”
The network is largely ready. “From a network point of view, we already had to optimize the network heavily for low latency,” Hošna explains. Low latency is hard because it removes the buffer that normally absorbs network problems. “You lose the time where the buffers can bridge over some network gap, where you have time to retry stuff, time to optimize stuff,” he says. “With any kind of low latency, this becomes much harder.”
CDN77 has already done that work. “We already did that on the network layer, because we already do a bunch of low latency stuff,” Hošna says. “It was hard to do, but we have our great networking team that was able to do this. So we already have it.”
What remains is edge software. “For the software on the edges, we need to integrate new software,” he says. “We are working on it, and we are working on an open source relay implementation in the OpenMOQ group.”
How the Rollout Will Work
Will MoQ arrive network-wide or in pockets? Hošna’s long-term goal is one platform for both protocols. “I would hope that we can get one unified software that can do both HTTP and MoQ in all locations,” he says, where the two “can share locations and work efficiently together.”
The first deployments will be more targeted. “We will probably start with bigger PoPs, bigger locations, roll them out, and start spreading capacity,” Hošna explains, “adding servers as dedicated things, separate from HTTP, to experiment and roll the stuff out.”
Timeline and Standardization
When can a live streamer call CDN77 and run a MoQ broadcast? “You should call us today,” Hošna says. “We probably won’t give you a relay today. But we can start.”
Why not today? Hošna calls it a chicken and egg problem. “It’s hard to build a public offering until we know what people actually want to run on it,” he explains, “because you would still build, at least the initial rollout, a little bit differently based on what people want to do with it.”
CDN77 already works this way with HTTP. “We don’t have one single universal CDN for everything,” Hošna says. “We have edges that are optimized for low latency, HTTP edges that are optimized for QUIC, and edges that are optimized for large files.” MoQ becomes one more deployment type. “This will be just another one. So I would expect we can start rolling out quickly.”
A Moving Standard
The larger constraint is the standard itself. “We still don’t have a final standard under IETF. There is still churn,” Hošna says. “We are slowly trying to deploy stuff, but we are not at the stage of large deployments or public offerings.”
He is candid about the schedule. “In the IETF working group, every six months we’ve been saying it will be done in six months, for two years,” Hošna says. Still, he sees progress. “We are at the 20th version of the draft, and we are finally, I think, stabilizing, solving issues, not adding new features. So hopefully by the end of this year we have something final.”
Real-world deployment keeps feeding the process. “As we start to deploy the stuff and do larger and larger scale experiments, we are finding problems with it,” Hošna says. “So we are still tweaking it, the whole IETF working group.”
If the standard lands on that schedule, CDN77 expects to move quickly. “We are already experimenting with it. The relay is being developed,” Hošna says. “It probably won’t be hundreds of thousands of users at the beginning, but some public offering in a couple of months” after the standard stabilizes.
Encoders, Players, and Devices
For most streaming services, the CDN is a black box. What matters is how to get a stream in and how to play it back. How ready is the ecosystem at each end?
Encoders
Encoder support is arriving through familiar tools. “There’s work to add MoQ support to OBS,” Hošna says. “I don’t think it’s in an official release, but you can get OBS plugins. There are pull requests into FFmpeg. There are hardware vendors that are trying to implement it.”
His expectation is broad coverage. “If you want to be an end-to-end user of MoQ, you should be able to select from all the classic vendors and all the classic open source stuff.”
Players
On playback, the key point is browser support. “MoQ works in the browser,” Hošna says. “It’s not some proprietary stuff where you have to have your own application.” Browsers already include the required foundation. “All major browsers have already shipped the underlying technology, WebTransport support, and there are already open source players available that you can use to start playing.”
Hošna acknowledges the ecosystem is young. “We are still in the early days,” he says. “We need everybody to get on the train at the same time, to have CDNs, players, and encoders. But there is already quite a lot of support there.”
Set-Top Boxes and Smart TVs
Living room devices depend on libraries more than browsers. “Hopefully you can also pick up an open source library,” Hošna says. He sees no fundamental barrier. “There shouldn’t be anything that’s hard about deploying MoQ, even on embedded and constrained devices.”
QUIC is the main hurdle, but developers are already clearing it. “We see deployments and working MoQ demos on the ESP32,” Hošna says, referring to the low-cost embedded microcontroller. “So MoQ should work even on limited embedded devices, and libraries exist for running in constrained environments.”
ABR, DRM, and Captions
HLS and DASH come with mature support for adaptive bitrate switching, DRM, and captions. Does MoQ match them? The answer depends on the streaming format layered on top of the transport.
“Now we are leaving the transport, MoQT, and looking more at the streaming format,” Hošna explains. “We have MSF and CMSF. So there will be the MoQ Streaming Format and then the CMAF version of that.”
DRM and Captions
CMSF brings existing CMAF workflows along. “Given that we have a CMAF version, you can transfer CMAF files unchanged over MoQT,” Hošna says. “So you get DRM and captions and all of that, which you can already do with CMAF.”
Adaptive Bitrate
ABR works today. “With ABR, I would say we are at parity with HTTP,” Hošna says. “You can do everything you can do in HTTP.”
The draft also aims to go further. “One of the still unfinished things in the MoQ draft is adding some ABR-specific features, so you can tell the server you want to switch at some point, and the server does the switchover for you,” he explains. The goal is efficiency during quality drops. “Especially when you are down-switching, you really don’t want to waste data on the wire. So there are talks about getting low-level primitives, so the relays can do that without wasting any data.”
MoQ Versus WebRTC
Many low-latency services run on WebRTC today, including social media, auctions, gambling and online betting. If the large CDNs all support MoQ, how does that change the choice? Hošna hopes MoQ eventually replaces WebRTC. “I would fully hope MoQ can replace WebRTC,” he says. He expects conferencing to be the hardest market to move.
Where WebRTC Holds On
WebRTC was built for browser conferencing, and it still does that job well. “Building a conference application that works in your browser is currently very easy,” Hošna says. MoQ asks more of developers. “MoQT gives you much lower level primitives, and you need to supply the higher level things with your own code, or some libraries you buy or get open source.”
That tradeoff cuts both ways. “This gives you more flexibility, but it’s harder to implement than WebRTC, which is fully in the browser with the full stack,” Hošna explains. “So for the classic conferencing applications, I would expect WebRTC to stay with us for some time.” Peer-to-peer connections are the strongest case. “Direct peer-to-peer is easier with WebRTC than with MoQT,” he says.
Where MoQ Takes Over
Everything else is open to MoQ. Hošna expects a shift wherever WebRTC has been stretched beyond conferencing. “For everything else that uses WebRTC and tries to hack it into stuff other than peer-to-peer conferencing, I would fully expect a move to MoQ, even as one of the early adopters,” he says.
The reason is scale. “WebRTC is not made for CDNs,” Hošna explains. “There are CDN offerings, but it’s not the main thing for CDNs. It doesn’t have this big push, because it’s hard to scale. It’s expensive to scale.” He expects the shift to come early. “I would think that MoQ will push out WebRTC in those use cases fairly early.”
How Adopters Will Decide
Will social media be the first to switch? Hošna frames it as a decision each service will make with its own data. “I expect that people will start experimenting with it,” he says. The decision will come down to measurable results. “Based on their business metrics, business goals, technical metrics, and all the trade-offs, they will decide and work with us and other vendors to see if MoQ makes sense for them.”
For services that need interactive, low-latency delivery at scale, that experimentation can start now. CDN77 is already running MoQ trials and developing its relay through OpenMOQ. The standard is on its 20th draft. Hošna hopes it will be final by the end of the year.
