Hector Martin

WebRTC works in practice, but is very heavy server-side. We use it for audio (<70ms latency end to end) but it's a lost cause for video with our infra.

Why is it heavy? Is it an issue with the server software or something more fundamental?

It's basically mandatory DTLS, which requires negotiating a 1:1 stream with each client, so multicast doesn't work. The server-side software stacks are a lot less mature than the HTTP ecosystem. It's possible but not nice.

ah. of course, for Internet streaming where multicast isn’t possible and the alternative is HLS over regular TLS, that should make less difference…

Yeah, but you're still dependent on a much messier multi-stream UDP protocol (with all the NAT hole punching and firewall bypassing stuff that brings), ICE/STUN/TURN, and all the complexity that brings.

and even if it works for most of your users, I feel a need to emphasize that the relevant hole-punching _does not always work_, so you're gonna need an HLS fallback, which means muxing two variants of everything (idk how RTP works) which sounds heckin' expensive

RTP doesn't even mux, you get two UDP streams, one for audio and one for video. Unless you do what ISPs do for TV over IP, which is also what we did for multicast: shove MPEG-TS into RTP, which is the only way to get a multicast stream that works in VLC with zero configuration.

have you seen ATSC 3.0? It's MPEG-DASH segments per-stream over "Route" (don't ask) over UDP over IP over terrestrial broadcast