The First Media over QUIC CDN: Cloudflare
47 comments
·August 22, 2025brycewray
englishm
Looks like it might be a happy eyeballs issue? I'll pass it along to folks who would know more about what that might be, thanks.
vient
Limited to macOS? Does not reproduce in FF 141 and 142 on Windows.
englishm
Hi! Cloudflare MoQ dev here, happy to answer questions!
Thanks for the award, kixelated. xD
VoidWhisperer
> No head-of-line blocking: Unlike TCP where one lost packet blocks everything behind it, QUIC streams are independent. A lost packet on one stream (e.g., an audio track) doesn't block another (e.g., the main video track). This alone eliminates the stuttering that plagued RTMP.
It is likely that I am missing this due to not being super familiar with these technologies, but how does this prevent desync between audio and video if there are lost packets on, for the example, the audio track, but the video track isn't blocked and keeps on playing?
englishm
Synchronized playback is usually primarily a player responsibility, not something you should (solely) rely on your transport to provide. We have had some talk about extensions to allow for synchronizing multiple tracks by group boundaries at each hop through a relay system, but it's not clear if that's really needed yet.
Essentially though, there are typically some small jitter buffers at the receiver and the player knows how draw from those buffers, syncing audio and video. Someone who works more on the player side could probably go into a lot more interesting detail about approaches to doing that, especially at low latencies. I know it can also get complicated with hardware details of how long it takes an audio sample vs. a video frame to actually be reproduced once the application sinks it into the playback queue.
madsushi
Depending on the streaming protocol (eg WARP), you can specify that the tracks (audio vs video) need to be time-aligned, so each group (chunk of video or audio) starts at the same time and lasts the same length. I think this means you'll get resync'd at the start of the next group.
kixelated
Each track is further segmented into streams. So you can prioritize new > old, in addition to audio > video.
torginus
Hi! I have a few :)
How close are we to having QUIC actually usable in browsers (meaning both browsers and infrastructure supports it, and it 'just works')
How does QUIC get around the NAT problem? WebRTC requires STUN/TURN to get through full cone NAT, particularly the latter is problematic, since it requires a bunch of infra to run.
englishm
QUIC is already quite widely used! We see close to 10% of HTTP requests using HTTP/3: https://radar.cloudflare.com/adoption-and-usage
As for the NAT problem, that's mainly an issue for peer-to-peer scenarios. If you have a publicly addressable server at one end, you don't need all of the complications of a full ICE stack, even for WebRTC. For cases where you do need TURN (e.g. for WebRTC with clients that may be on networks where UDP is completely blocked), you can use hosted services, see https://iceperf.com/ for some options.
And as for MoQ - the main thing it requires from browsers is a WebTransport implementation. Chrome and Firefox already have support and Safari has started shipping an early version behind a feature flag. To make everything "just work" we'll need to finish some "streaming format" standards, but the good news is that you don't need to wait for that to be standardized if you control the original publisher and the end subscriber - you can make up your own and the fan out infrastructure in the middle (like the MoQ relay network we've deployed) doesn't care at all what you do at that layer.
kixelated
Chrome and Firefox support WebTransport. Safari has announced intent to support it and they already use QUIC under the hood for HTTP/3.
Cloud services are pretty TCP/HTTP centric which can be annoying. Any provider that gives you UDP support can be used with QUIC, but you're in charge of certificates and load balancing.
QUIC is client->server so NATs are not a problem; 1 RTT to establish a connection. Iroh is an attempt at P2P QUIC using similar techniques to WebRTC but I don't think browser support will be a thing.
valorzard
Last I checked, Iroh is gonna use WebRTC datachannels to run QUIC over SCTP
combyn8tor
Is the load balancing of the relays out of scope? It doesn't seem to be addressed in the write up unless I missed it.
kixelated
I've got a blog post almost ready to go, just needs to be cleaned up. I go over a bunch of different architectures and the pros/cons.
`relay.moq.dev` currently uses GeoDNS to route to the closest edge. I'd like to use anycast like Cloudflare (and QUIC's preferred_address), but cloud offerings for anycast + UDP are limited.
The relays nodes currently form a mesh network and gossip origins between themselves. I used to work at Twitch on the CDN team so I'd like to eventually add tiers, but it's overkill with near zero users.
The moq-relay and terraform code is all open source if you're super curious.
tschellenbach
hi, I work on our webrtc streaming over at getstream.io
webrtc has a lot of annoying setup. but after it connects it offers low latency. how do you feel MoQ compares after the connection setup is completed? any advantages/ any issues?
kixelated
QUIC/WebTransport gives you the ability to drop media, either via stream or datagrams, so you can get the same sort of response to congestion as WebRTC. However, one flaw with MoQ right now is that Google's GCC congestion controller prioritizes latency over throughput, while QUIC's TCP-based congestion controllers prioritize throughput over latency. We can improve that on the server side, but will need browser support on the client side.
As for the media pipeline, there's no latency on the transmission side and the receiver can choose the latency. You literally have to build your own jitter buffer and choose when to render individual frames.
valorzard
Quic (ha) thing:
Webtransport on Firefox currently has issues See: https://bugzilla.mozilla.org/show_bug.cgi?id=1969090
wiradikusuma
Since it's "under the hood" as long as major browsers support it (I can't even find in caniuse?) it's good.
And I guess if webview engines like Microsoft Edge WebView2 supports it then developers can use it immediately (wrapping it).
But how about from the other side, I guess OBS and YouTube must start supporting it to actually be useful?
englishm
So... MoQ represents a bit of a moving away from the all-in-one "black box" of web APIs like WebRTC. From the browser perspective, the main thing that matters is the WebTransport API. Using MoQT in conjunction with that WebTransport API, you now have various options for rendering the video as a player, for example: WebCodecs. But, if you can afford a bit more latency, you can also use APIs like MSE for playback and be able to use DRM.
And yeah, being able to publish from something like OBS is something I worked on before joining Cloudflare, but it depends a lot on what you do at the "streaming format" layer which is where all the media-aware details live. That layer is still evolving and developing with WARP being the leading spec so far. As that gels more, it'll make sense to bake things into OBS, etc. Already today though you can use Norsk (https://norsk.video/) to publish video using a rudimentary fMP4-based format similar to early versions of the WARP draft.
As for YouTube, Google has some folks who have been very active contributors to MoQT, but I'm not certain exactly how/where/when they plan to deploy it in products like YouTube.
hn-user-42
I found your first app interesting. You should submit it as Show HN.
I used to work in live video platform. I have found MoQ interesting enough to work on it again.
kixelated
Yeah I will soon, but I could also use the time to fix up some more stuff.
madsushi
Related, the WARP streaming protocol, as a candidate for what would ride over MoQ: https://datatracker.ietf.org/doc/draft-ietf-moq-warp/
englishm
Yes, exactly! I mention that in the post. Streaming formats are where a lot of interesting decisions can be made about how best to optimize QoE for different use cases. MoQT is designed have enough levers to pull to enable a lot of clever tricks across a wide gamut of latency targets, while also being decoupled from all of the media details so we can get good economies of scale sharing fan out infrastructure.
WARP's development up until now has been largely spearheaded by Will Law, but it's an IETF spec so anyone can participate in the working group and help shape what the final standard looks like. WARP is a streaming format designed mainly for live streaming use cases, and builds on a lot of experience with other standards like DASH. If that doesn't fit your use case, you can also develop your own streaming format, and if it's something you think others could benefit from, too, you could bring it to the IETF to standardize.
kixelated
Hi I originally wrote WARP and used something similar at Twitch. It supports CMAF segments, so the media encoding is backwards compatible with HLS/DASH and can share a cache, which is a big deal for a gradual production rollout.
madsushi
Thanks for the info! I was reading up on CMAF after seeing it mentioned on your blog.
hn-user-42
Some interesting stuffs and more technical details
dang
(the first URL is same as OP because we merged this comment from a different thread - https://news.ycombinator.com/item?id=44984785)
englishm
Thank you dang!
MattRix
A small note: I found the styling of your post made it annoying to read. You shouldn’t highlight key words so strongly, especially using the same green you’re using for links. It makes it take mental effort to tell them apart.
pphysch
Could MoQ be used for low-latency multiplayer/game networking in the browser?
englishm
You might be interested in looking at this RTC example for ideas about how to make bi-directional data flows for arbitrary groups of participants (or players) work through a relay.
It uses a feature we haven't yet implemented, but we're thinking about how we might implement it at our scale, SUBSCRIBE_ANNOUNCES[1].
[1]: https://www.ietf.org/archive/id/draft-ietf-moq-transport-12....
englishm
It could! We've mainly been focused on using it for audio and video for live streaming and RTC use cases, but the MoQT layer is very intentionally decoupled from the media details so the fan out infrastructure could actually be used for a lot of different things. You'd need to decide how you want to map your data to MoQT objects, groups, tracks, etc.
pphysch
Sweet, thanks! I'll tinker with it.
dang
Comments moved to https://news.ycombinator.com/item?id=44984785, which has the original source. (Edit: I mean the announcement this article is reporting on.)
Submitters: "Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html
Edit: since people seem to agree that this was the wrong move, I'm going to undo it.
Edit 2: undone now!
kixelated
Hey dang, I don't think my blog is a repost. It links the Cloudflare announcement but the content is completely different (and actually funny). Is there any way you could restore it?
dang
It's not that it's a repost; it's that it's mostly reporting on the content of another article. In such cases it's standard HN practice to prefer the latter, as the guidelines say (and have said since ancient times). It's not that you did anything wrong! and I'm sorry, I know it sucks to have an article doing well on the frontpage and then plummet for no obvious reason. But from a mod practice point of view this is a pretty clear call.
englishm
(OP of the Cloudflare blog & submission here) I think kixelated is saying enough stuff beyond our post that he deserves the credit for and this shouldn't be treated as a dupe. (emailed to say as much also)
kixelated
I linked the URL to their relay but otherwise all of the libraries, demos, rants, jokes are my own. I can remove the link to their post if that would help, or I could get Cloudflare's blessing. It's just a bit frustrating.
null
hn-user-42
What? did you check the source? he is the original guy.
dang
The article is about a Cloudflare announcement. The original source in that case would be the Cloudflare announcement, no?
therein
Pretty cool. Correct me if I'm wrong, this only works on Chrome?
englishm
Firefox also has WebTransport support and Safari has a work-in-progress implementation behind a developer mode feature-flag. Safari used to not work at all, but I know they've been putting more effort into it lately, so hopefully we'll be able to use MoQ in all three soon!
therein
I tried on FF (Floorp fork) and it said no browser support but I have all sorts of extensions like Chameleon etc. so it is probably a problem on my end that interfered with feature detection.
Works really nicely on Chrome, though. Looking forward to the Safari support as I find myself using Orion more and more.
conradfr
It works for me on FF macOS but not FF Android.
(meaning the link before the edit, https://moq.dev/watch/)
kixelated
Firefox should work, I just don't test it often. Lemme fix.
Semi-related and just FYI for Firefox users who visit Cloudflare-hosted, HTTP/3-using sites:
https://bugzilla.mozilla.org/show_bug.cgi?id=1979683