Not OP, but the distinction is between live streams where the content is being generated very close to the consumption time (historically delivered using RTSP) and between static files sitting on a server/CDN (ie. Netflix, Youtube, etc.)
This is exactly the distinction I'm talking about.
Doing it live is way harder than moving static content out to all the leaf nodes once per day and serving it to a geographically small region.
Adaptive bitrate has nothing to do with the point I'm making that, AFAIK, twitch has the most "live" eyeballs out of anyone and there are special engineering challenges there.
Well, no Twitch isn't the largest. NBC/Comcast moved several orders of magnitude more of live video for the last olympics, and those numbers went up substantially this year+.
Live presents interesting challenges yes, but in some ways it is easier than VOD from a scale perspective. In live all users are watching essentially the same content++, so it is nearly perfectly cacheable in memory. That means you don't really need a ton of cache, just a cdn with lots NIC's, ram, and CPUs. You can use mid-tier caches to "fan" out data to edge caches and progressively deload origins. You can take a look at our architecture over here https://www.bizety.com/2015/07/15/deep-dive-comcast-cdn-arch....
The really hard problems with live are actually the surrounding items. If you are placing personalized ads, and 100 million people are watching a stream, your system must support 100million transactions per second. If you have QOS data from clients, you need to support 100 million TPS. Etc, etc.
Building live packagers and segmenters is also a serious bit of work. Especially to "broadcast" standards. This requires the coordination of multiple video streams subject to byzantine failure.
I guess the hardest scale problem though is probably emergency alerts. In this situation all users will tune at almost precisely the same time to a live streaming event. 30million + users can arrive on a single (previously cold) item in < 100ms. Just opening that many tcp sockets is serious work even for large numbers of servers.
+
(sauces so I don't get in trouble, full disclosure I designed and work on the systems that do this):
I'm actually not sure what's more intriguing or impressive -- the fact that the [streamer for high-profile event] spins up so much infrastructure and machinery for a duration of 2-3 weeks and then spins it down until the next high-profile event two years later, or someone like Twitch who does it on a smaller scale, but 24/7.
Though in my mind, the illusion or appearance of 'pop-up streaming' takes the award. I wonder, how much streaming infrastructure and instrumentation and code can someone like NBC reuse between two successive olympics (two years apart)?
Seems like that could be a big moneymaker for them, for these big time events that need a "live" aspect.