> What about actual live events? My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay relative to realtime, specifically to allow for significant buffering on the client, and then using reliable TCP faster-than-realtime downloads of the "near future" of the video content. Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live. (I don't understand how this interacts with the typical ability to start watching almost instantly, with no visible buffering delay, though.)

For TV, last I worked on a system like this the clients received data the same way as non-live streams: Http streaming (HLS or Dash), where you fetch playlists and small video files and the player stitches them all together. There's buffering along the pipe, the 30-60s total delay (which you'll notice if you watch sports and chat with someone who has cable and is watching the same thing) is a cumulative thing, so you don't see a 1-min startup delay, you just near-instantly get dropped into something that's already quite a bit behind.

Not sure what Twitch does. The over-the-network video game streaming-console services are obviously completely different from TV land, they couldn't get away with it there; but for TV the expense of better isn't seen worth it.