QUIC is a major functionality improvement, while IPv6 is a capacity improvement. You can do some extremely cool things with QUIC that definitely deserves a post of its own.
ABR is absolutely required for distribution. MoQ also supports ABR, but additionally gives you the ability to also drop the tail of a GoP if a rendition switch is too slow, or no lower rendition exists.
As for maintaining existing standards, it depends on your goals. If you're not trying to push boundaries then absolutely, HLS/DASH is great for quickly getting off the ground. But if you're looking for something in-between HLS and WebRTC then MoQ is compelling.
Yeah, if you're using WebRTC only for data channels, then 100% you should switch to WebTransport with all due haste. Once Safari adds support of course.
This is what I profoundly disagree about, and I am referring to native code, not in browsers.
The whole P2P, STUN/TURN/ICE integration has value far beyond just media streaming, especially for large amounts of real time data where the central node doesn't want to be handling the data itself.
There are definite oddities to it but having the P2P setup and negotiation working (and QAed, as pointed out) is huge.
It's really difficult to compare the latency of different protocols because it depends on the network conditions.
If you assume flawless connectivity, then real-time latency is trivial to achieve. Pipe frames over TCP like RTMP and bam, you've done it. It's almost meaningless to compare the best-case latency.
The important part is determining how a protocol behaves during congestion. LL-HLS doesn't do great in that regard; frankly it will perform worse than RTMP if that's our yardstick because of head-of-line blocking, large fragments, and the playlist in the hot path. Twitch uses a fork of HLS called LHLS which should have lower latency, but we were still seeing 3-5s in some parts of the world.
But yeah, P90 matters more than P10 when it comes to latency. One late frame ruins the broth. A real-time protocol needs a plan to avoid queues at all costs and that's just difficult with TCP.
I'm doing that in my implementation: the main thread immediately transfers each incoming QUIC stream to a WebWorker, which then reads/decodes the container/codec and renders via OffscreenCanvas.
I didn't realize that DataChannels were main thread only. That's good to know!
Eric Kinnear (linked post; Apple) is the author of the HTTP/2 fallback for WebTransport, so it's safe to say that WebTransport will be available in WebKit at some point.
It's just a lot of work to get everything right. It's kind of working, but I removed synchronization because the signaling between the WebWorker and AudioWorklet got too convoluted. It all makes sense; I just wish there was an easier way to emit audio.
While you're here, how difficult would it be to implement echo cancellation? The current demo is uni-directional but we'll need to make it bi-directional for conferencing.
Are you referencing this line?
> 2x the packets, because libsctp immediately ACKs every “datagram”.
The section is about data channels, which uses SCTP and is ACK-based. Yes, you can use RTP with NACK and/or FEC with the media stack, but not with the data stack.
