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

81–90 of 125 posts

Re: The first Media over QUIC CDN: Cloudflare

#81

Post by vlovich123 »

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…

If you’re delivering audio and video separately the blocking is irrelevant for needing to solve synchronization. That’s why some amount of buffering (a few frames of video at least) on the receiver is needed to hide the jitter between packets / make sure you have the video. You can go super low latency with no buffering but then you need to drop out video / audio when issues occur and those will be visible as glitches - depends on how good your network is.

Re: The first Media over QUIC CDN: Cloudflare

#82

Post by solardev »

barosl wrote: post #49

I tested the demo at https://moq.dev/publish/ and it's buttery as hell. Very impressive. Thanks for the great technology! Watching the Big Buck Bunny demo at https://moq.dev/watch/?name=bbb on my mobile phone leaves a lot of horizontal black lines. (Strangely, it is OK on my PC despite using the same Wi-Fi network.) Is it due to buffer size? Can I increase it client-side, or should it be done server-side? Also, thank…

Is it Chrome only? On Android Firefox it just says no browser support :(

Re: The first Media over QUIC CDN: Cloudflare

#83

Post by bb88 »

barosl wrote: post #49

I tested the demo at https://moq.dev/publish/ and it's buttery as hell. Very impressive. Thanks for the great technology! Watching the Big Buck Bunny demo at https://moq.dev/watch/?name=bbb on my mobile phone leaves a lot of horizontal black lines. (Strangely, it is OK on my PC despite using the same Wi-Fi network.) Is it due to buffer size? Can I increase it client-side, or should it be done server-side? Also, thank…

On a mac book air m4 with a 600mbps connection, it's instantaneous and amazing.

Re: The first Media over QUIC CDN: Cloudflare

#84

Post by simmervigor »

Nathan2055 wrote: post #67
brycewray wrote: post #42

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

Hmm…do you have the in-browser DNS over HTTPS resolver enabled? I personally can't reproduce this, but I'm using DoH with 1.1.1.1. I've noticed that both Chrome and Firefox tend to have less consistent HTTP/3 usage when using system DNS instead of the DoH resolver because a lot of times the browser is unable to fetch HTTPS DNS records consistently (or at all) via the system resolver. Since HTTP/3 support on the serve…

> If anyone from Cloudflare happens to be reading this, you should know that you have some kind of misconfiguration

Thanks for the detailed information. I'm a someone from Cloudflare responsible for this, we'll get it looked at.

Re: The first Media over QUIC CDN: Cloudflare

#86

Post by chrismorgan »

kixelated wrote: post #51
barosl wrote: post #49

I tested the demo at https://moq.dev/publish/ and it's buttery as hell. Very impressive. Thanks for the great technology! Watching the Big Buck Bunny demo at https://moq.dev/watch/?name=bbb on my mobile phone leaves a lot of horizontal black lines. (Strangely, it is OK on my PC despite using the same Wi-Fi network.) Is it due to buffer size? Can I increase it client-side, or should it be done server-side? Also, thank…

Horizontal black lines? Dunno what that could be about, we render to a element which is resized to match the source video and then resized again to match the window with CSS.

What’s that like for performance and power usage? I understand normal videos can generally be entirely hardware-accelerated so that the video doesn’t even touch the CPU, and are passed straight through to the compositor. I’m guessing with this you’re stuck with only accelerating individual frames, and there’ll be more back and forth so that resource usage will probably be a fair bit higher?

An interesting and unpleasant side-effect of rendering to canvas: it bypasses video autoplay blocking.

Re: The first Media over QUIC CDN: Cloudflare

#87

Post by bushbaba »

kixelated wrote: post #48
combyn8tor wrote: post #46

Earlier quoted context omitted.

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.

EDIT: Sorry I just noticed this was directed to Cloudflare. They're using the same architecture as Cloudflare Realtime, their WebRTC offering. `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.…

Anycast can have serious reliability challenges. It was common at GCP for a small QPS user of anycast to have their Load Balancers nuked in a given pop as it was backed by a single machine. But BGP showed it as still the best route. The major DNS based offerings don't have such issues.

Re: The first Media over QUIC CDN: Cloudflare

#88

Post by wbl »

bushbaba wrote: post #87
kixelated wrote: post #48

Earlier quoted context omitted.

EDIT: Sorry I just noticed this was directed to Cloudflare. They're using the same architecture as Cloudflare Realtime, their WebRTC offering. `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.…

Anycast can have serious reliability challenges. It was common at GCP for a small QPS user of anycast to have their Load Balancers nuked in a given pop as it was backed by a single machine. But BGP showed it as still the best route. The major DNS based offerings don't have such issues.

I work for a CDN that does DNS steering. DNS record lifetimes are nonzero and can be surprisingly long. But you do get some very fine control over where data goes if resolvers cooperate.

Re: The first Media over QUIC CDN: Cloudflare

#89

Post by kixelated »

chrismorgan wrote: post #86
kixelated wrote: post #51

Earlier quoted context omitted.

Horizontal black lines? Dunno what that could be about, we render to a element which is resized to match the source video and then resized again to match the window with CSS.

What’s that like for performance and power usage? I understand normal videos can generally be entirely hardware-accelerated so that the video doesn’t even touch the CPU, and are passed straight through to the compositor. I’m guessing with this you’re stuck with only accelerating individual frames, and there’ll be more back and forth so that resource usage will probably be a fair bit higher? An interesting and unpleas…

It's all hardware accelerated, assuming the VideoDecoder has hardware support for the codec. VideoFrame is available in WebGL and WebGPU as a texture or gpu-buffer. We're only rendering after a`requestAnimationFrame` callback so decoded frames may get automatically skipped based on the display frame rate.

I don't think the performance would be any worse than the tag. The only exception would be browser bugs. It definitely sounds like the black bars are a browser rendering bug given it's fine when recorded.

Re: The first Media over QUIC CDN: Cloudflare

#90

Post by kixelated »

chrismorgan wrote: post #86
kixelated wrote: post #51

Earlier quoted context omitted.

Horizontal black lines? Dunno what that could be about, we render to a element which is resized to match the source video and then resized again to match the window with CSS.

What’s that like for performance and power usage? I understand normal videos can generally be entirely hardware-accelerated so that the video doesn’t even touch the CPU, and are passed straight through to the compositor. I’m guessing with this you’re stuck with only accelerating individual frames, and there’ll be more back and forth so that resource usage will probably be a fair bit higher? An interesting and unpleas…

Oh and the autoplay restrictions for don't apply when muted.
Post reply on HN