3
points
kixelated
Joined 360 karma
- QUIC has a much better alternative to FORWARD-TSN, either via RESET_STREAM or QUIC datagrams.
I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fun fact: you can't use FORWARD-TSN if there's still reliable data outstanding. TSN is sequential after all, you have to drop all or nothing.
QUIC as a protocol is significantly better than SCTP. I really recommend the RFC
- I like to frame WebTransport as multiple WebSocket connections to the same host, but using a shared handshake.
It's common to multiplex a WebSocket connection but you don't need that with WebTransport, while also avoiding head-of-line-blocking.
But yeah I wish WebTransport had a better TCP fallback. I still use WebSocket for that.
- I maintain https://github.com/kixelated/web-transport
But yeah the HTTP/3 integration definitely makes WebTransport harder to support. The QUIC connection needs to be shared between HTTP/3 and WebTransport.
- SCTP and by extension, WebRTC data channels, are supposed to use the same congestion control algorithms as TCP/QUIC. But I don't know which CC libsctp does these days.
WebTransport in Chrome currently uses CUBIC but the Google folks want to turn on BBR everywhere. It uses the same QUIC implementation as HTTP/3 so it's going to be more battle hardened.
- I had a 30 minute intro call and got a rejection a few days later. It was VERY timely (Sep 21 email, Sep 23 meeting, Sep 26 rejection).
We both weren't sure if my project was a good fit for the program. It was still a positive experience, and they were nice enough to offer me an intro to a more relevant team within OpenAI.
I couldn't quite figure out the goal of Grove. The line about "pre-idea" individuals, and of course the referral offer, made me feel that it's more of a hiring pipeline and not a traditional incubator. But we'll see when they announce the cohort.
- Thanks!
You don't need multicast! CDNs effectively implement multicast, with caching, in L7 instead of relying on routers and ISPs to implement it in L3. That's actually what I did at Twitch for 5 years.
In theory, multicast could reduce the traffic from CDN edge to ISP, but only for the largest broadcasts of the year (ex. Superbowl). A lot of CDNs are getting around this by putting CDN edges within ISPs. The smaller events don't benefit because of the low probability of two viewers sharing the same path.
There's other issues with multicast, namely congestion control and encryption. Not unsolvable but the federated nature of multicast makes things more difficult to fix.
Multicast would benefit P2P the most. I just don't see it catching on given how huge CDNs have become. Even WebRTC, which would benefit from multicast the most and uses RTP (designed with multicast in mind) has shown no interest in supporting it. But I did hear a rumor that Google was using multicast for Meets within their network so maaaybe?
- 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 <video> 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.
- 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.
- Yeah, and CMAF is just a fancy word for fMP4. The f in fMP4 meaning an MP4 file that has been split into fragments, usually at keyframe boundaries, but fragments can be as small as 1 frame if you're willing to put up with the overhead.
The Big Buck Bunny example on the website is actually streamed using CMAF -> MoQ code I wrote.
- https://caniuse.com/webtransport https://caniuse.com/webcodecs
Technically, WebCodecs is not required since you can use MSE to render, but it's more work and higher latency.
Working on a WebSocket fallback and OPUS encoder in WASM to support Safari.
- 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. 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.
- That is all sorts of miserable. I had an initial prototype that emulated UDP over SCTP, running QUIC (without encryption) on top. The problem is that SCTP becomes the bottleneck, plus it's super complicated.
I immediately jumped ship to WebTransport when Chrome added support. But I suppose there's no other option if you need P2P support in the browser.
- 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.
- 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.
And yeah, the usual approach is to adapt your bitrate to network conditions, but it's also common to modify the frame rate. There's actually no requirement for a fixed frame rate with video codecs. It also you could do the same "encode on demand" approach with a codec like H.264, provided you're okay with it being low FPS on high RTT connections (poor Australians).
Overall, using keyframes only is a very bad idea. It's how the low quality animated GIFs used to work before they were secretly replaced with video files. Video codecs are extremely efficient because of delta encoding.
But I totally agree with ditching WebRTC. WebSockets + WebCodecs is fine provided you have a plan for bufferbloat (ex. adaptive bitrate, ABR, GoP skipping).