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…
The first Media over QUIC CDN: Cloudflare
111–120 of 125 posts
Re: The first Media over QUIC CDN: Cloudflare
#112Re: The first Media over QUIC CDN: Cloudflare
#113Earlier quoted context omitted.
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 defin…
Unfortunately canvas (rgb'ish) can't overlay as efficiently as (yuv'ish), so there is some power cost relative to the lowest power video overlays. It really only matters in long form content where nothing else on the page is changing though.
Did you not just describe at least 99% of all web video?
Re: The first Media over QUIC CDN: Cloudflare
#114Earlier quoted context omitted.
Unfortunately canvas (rgb'ish) can't overlay as efficiently as (yuv'ish), so there is some power cost relative to the lowest power video overlays. It really only matters in long form content where nothing else on the page is changing though.
> It really only matters in long form content where nothing else on the page is changing though. Did you not just describe at least 99% of all web video?
Re: The first Media over QUIC CDN: Cloudflare
#115Earlier quoted context omitted.
On a mac book air m4 with a 600mbps connection, it's instantaneous and amazing.
with this pc spec and internet speed, I expect its "normal"
Re: The first Media over QUIC CDN: Cloudflare
#116Re: The first Media over QUIC CDN: Cloudflare
#117There's a whole "why should I care?" section in this breathless post that doesn't explain how Media over QUIC benefits either media publishers or end users - the two most important (perhaps the only important) parties involved in this exchange. So, why should I care?
My fault, I trying too hard to avoid rehashing previous blog posts: https://moq.dev/blog/replacing-webrtc/ And you're right that MoQ primarily benefits developers, not end users. It makes it a lot easier to scale and implement features; indirect benefits.
Re: The first Media over QUIC CDN: Cloudflare
#118Why? Because transcoding = latency. Back in the day clients were weak, so transcoding on the server made sense. Today your phone can easily spew multiple streams out without breaking a sweat.
Assuming a capable device, it would provide the fastest path. And it doesn't obviate transcoding.
Re: The first Media over QUIC CDN: Cloudflare
#119GitHub: https://github.com/winkmichael/mediamtx-moq
We implemented both WebTransport (for browsers) and native QUIC (for server-to-server) after discovering browsers block raw QUIC. Works today in Chrome/Edge, integrates with existing RTMP/RTSP streams in MediaMTX.
Re: The first Media over QUIC CDN: Cloudflare
#120Hi! Cloudflare MoQ dev here, happy to answer questions! Thanks for the award, kixelated. xD
Also our take on MoQ https://www.wink.co/documentation/WINK-MoQ-Implementation-An...