There could be a #4 "historically, streaming could use protocols with unreliable delivery and with limited or no retransmission" (which is somewhat related to #1 and #2). For example, there have been media streaming protocols built on UDP rather than TCP, so packets that are lost are not automatically retransmitted. The idea is that for a real-time stream transmission, older frames are no longer considered relevant (as they would not be rendered at all if they were received late), so there is typically no benefit in retransmitting a dropped packet.
That means you could get drop-outs when data gets lost in transmission, but the overall data consumption of the protocol wouldn't go up as a result.
Not all that long ago, this prompted lots of debate about QoS and prioritization and paid prioritization and network neutrality and stuff. People were arguing that media streams needed higher priority on the Internet than downloads (and other asynchronous communications). Effectively, different Internet applications were directly competing with one another, yet they had very different degrees of tolerance to delays, packet reordering, and packet loss. Wouldn't ISPs have to intervene to prioritize some applications over others?
I remember reading from Andrew Odlyzko that this controversy was mostly resolved in an unexpected way: faster-than-realtime streams with buffering (as the network was typically faster overall than what was needed for a given level of media quality, you could use TCP to reliably download frames that were still in the future with respect to what would be played, and then buffer those locally). This is indeed the scenario depicted in this article.
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.)
There's a big difference for bidirectional conversation, like phone calls, because there even tiny delays are extremely psychologically noticeable. It appears that Zoom, for instance, is still using unreliable UDP streams for call content, which allows skips or dropouts, but keeps the latency relatively low so that it feels comparatively more like a face-to-face interactive conversation.
> My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay relative to realtime,
Yeah. The rule of thumb with Twitch used to be 11 seconds. You can still measure this because many streams replay the chat in the stream as an overlay for both being able to see when the streamer has seen your message and for archival purposes to preserve the chat in VODs.
> don't understand how this interacts with the typical ability to start watching almost instantly, with no visible buffering delay, though.
There's a buffer on the CDN (which they have anyways because they're recording the VOD) and you start playback at the point t seconds back.
There is a low-latency mode for twitch now that I think is enabled by default. The actual delay is reported in the "stats" view under advanced settings, probably coming from timestamps in the video metadata. There's third-party twitch clients I've used with the option to delay the chat to match the video using this information, which would be useful if you didn't want chat popping off to spoil you.
>Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live.
Plenty of streamers show the chat on screen and talk with people in the chat. This is not true.
Good point. I didn't think of that, but that's right.
I have seen significant delays in that situation, so maybe a better way to say this is "using text rather than voice for feedback makes the delays introduced this way less psychologically noticeable" (because they are noticeable in the situation you mention).
It is still noticeable. When beam.pro rolled their low latency streaming (~100ms) streamers and chatters commented on how much more enjoyable and natural chatting was when things had less latency.
On the grasping hand, sometimes the feed is deliberately delayed, such as when the streamer is showcasing some kind of competitive activity wear their own information could be used against them.
> 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.
Twitch is HLS, but they've tightened the buffers and shortened the segments (2s is standard) so that latencies of down to a couple of seconds is common. It's quite impressive, tbh.
> Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live.
This can be a problem, for example when sports fans receive out-of-band notification of a goal before they see it happen on their "live" stream.
No need for notifications even, you can literally hear latency varying up to 30 seconds by listening for cheers during important game in a block of flats on a warm summer night.
> cheers during important game in a block of flats
Yes, that is what rlpb wrote: soundwaves are richly descriptive out-of-band notifications!
It also makes it impossible to watch a live updating box score without spoilering yourself since it updates before the stream.
> My impression is that Twitch and YouTube livestreaming are using a 10-30 second delay
This used to be the case, and may still be for some steamers, but mostly when I watch it's less than a couple seconds delay with the low latency mode enabled in the browser.
When setting up a YouTube livestream I can choose if it has a delay or not.
...you could use TCP to reliably download frames that were still in the future with respect to what would be played, and then buffer those locally)
With YouTube on desktop, you can right click and turn on "Stats for Nerds" to watch the buffer health in realtime to see how much buffer it has decided your connection needs and how often it refills it
Netflix has a similar feature, but it's more hidden.
Netflix appears to download the entire title upfront. I’ve had outages go unnoticed until the end of the episode.
My Chromecast probably doesn't have enough storage to buffer an entire episode.
>Since these streams are purely unidirectional, users don't have a way to notice that they're not literally live.
Depending on the delay, this can cause problems when switching from delayed streaming to real life. For example, watching the countdown on a rocket launch via streaming then going outside to watch the actual launch. Usually, for me, a few seconds delay is OK, because I can't see the rocket until about 30 seconds after liftoff due to trees. But when I have a better view of the launch pad the delay can become an issue.