[Sesse__]

The irony is that you don't _actually_ need WebRTC to get subsecond latency; you can fairly reliably get ~100–200ms (plus network latency) with a completely normal TCP stream.[1] But since browsers have effectively standardized on HLS, whose design is completely antithetical to low-latency (you _can_ do low-latency HLS, but only with heroic efforts), low-latency streaming video has never really been part of their bread and butter. So instead, we abuse a _much_ more complicated protocol (WebRTC), because that happens to hit a path that was meant for low-latency videoconferencing.

(I did sub-100ms glass-to-glass streaming with VLC back in the day, so it is eminently possible. But the browser is in your way.)

[1] Much less than that is going to be tricky under non-perfect network conditions, because once you start having any sort of packet drop, you want to go from TCP's retransmission regime and instead start dropping packets, take the artifacts for a little while, and then go on.

[numpad0]

  node1# nc -u node2 12345 < /dev/fb0
  node2# nc -lu 12345 > /dev/fb0

The "sub-second latency" thing is the standardized punchline coming from WebRTC folks, but yes, it's confusing. Nothing can make video flow faster than above, only thing you can do by inventing a new standard is to minimize the overhead you must add for your purposes.

[Sean-Der]

I saw this also. WebRTC just is the path of least resistance/highest adoption at this point.

We could go make a better/simpler standard for video streaming that is TCP. What a giant battle though that would never seen adoption .

I have accepted/embraced the challenge of making WebRTC as accessible as possible. Stuff like WebRTC for the Curious in hopes of making it less painful for everyone dealing with the complexity :)

[Sesse__]

> We could go make a better/simpler standard for video streaming that is TCP. What a giant battle though that would never seen adoption .

What do you mean? <video> in HTTP against a stream works, you don't need a new standard. But it's not a low-latency path (you cannot control the buffer).

[raymond_goo]

Explanation: HTTP Live Streaming slices the bitstream into “segments” (traditionally 6–10 s each) and only starts playing after it has downloaded several of them. Out of the box that means 30–60 s of startup and live-edge latency—fine for linear TV, terrible for anything interactive.

Apple’s LL-HLS spec shrinks those segments into “partial segments” and uses CMAF to let the player start decoding while a chunk is still arriving. With careful encoder tuning, HTTP/2/3 push, CDN support, and a compatible player you can reach 2–5 s, sometimes a bit lower—but every link in the chain has to cooperate, so implementations are still called “heroic” for a reason.

Safari plays HLS natively and on other browsers you can bolt on hls.js via Media Source Extensions. DASH, RTMP, SRT, etc. all need extra code or plugins, so HLS became the “safe default” for on-demand and broadcast-style streaming even though it isn’t low-latency friendly.

[_flux]

And in real world (e.g. mobile networks) there is going to be packet loss, so TCP is a non-starter for production-quality real-time streaming.