Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The first Media over QUIC CDN: Cloudflare

moq.dev

Post reply on HN
Print view View original

31–40 of 125 posts

Re: The first Media over QUIC CDN: Cloudflare

#31

Post by englishm »

wiradikusuma wrote: post #24

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?

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.

Re: The first Media over QUIC CDN: Cloudflare

#32

Post by kixelated »

torginus wrote: post #26
englishm wrote: post #3

Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD

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.

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.

Re: The first Media over QUIC CDN: Cloudflare

#33

Post by englishm »

torginus wrote: post #26
englishm wrote: post #3

Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD

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.

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.

Re: The first Media over QUIC CDN: Cloudflare

#34

Post by VoidWhisperer »

englishm wrote: post #3

Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD

> 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?

Re: The first Media over QUIC CDN: Cloudflare

#36

Post by madsushi »

kixelated wrote: post #27
madsushi wrote: post #2

Related, the WARP streaming protocol, as a candidate for what would ride over MoQ: https://datatracker.ietf.org/doc/draft-ietf-moq-warp/

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.

Thanks for the info! I was reading up on CMAF after seeing it mentioned on your blog.

Re: The first Media over QUIC CDN: Cloudflare

#37

Post by kixelated »

VoidWhisperer wrote: post #34
englishm wrote: post #3

Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD

> 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 a…

Each track is further segmented into streams. So you can prioritize new > old, in addition to audio > video.

Re: The first Media over QUIC CDN: Cloudflare

#38

Post by madsushi »

VoidWhisperer wrote: post #34
englishm wrote: post #3

Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD

> 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 a…

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.

Re: The first Media over QUIC CDN: Cloudflare

#39

Post by englishm »

VoidWhisperer wrote: post #34
englishm wrote: post #3

Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD

> 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 a…

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.

Re: The first Media over QUIC CDN: Cloudflare

#40

Post by valorzard »

kixelated wrote: post #32
torginus wrote: post #26

Earlier quoted context omitted.

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.

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 atte…

Last I checked, Iroh is gonna use WebRTC datachannels to run QUIC over SCTP
Post reply on HN