3 ms·

I imagine live video is a lot more expensive too. Can't just throw that on a CDN. And unlike YT or TikTok videos with sort of a time limit, Twitch streams can r

I imagine live video is a lot more expensive too. Can't just throw that on a CDN. And unlike YT or TikTok videos with sort of a time limit, Twitch streams can run for hours, chewing up bandwidth while so many "viewers" are giving divided attention at best.

itsTyrion 3y ago
exactly. Let's assume 1k viewers and 2/3 of them watching on 'source' quality, which is usually 6 mbps. In this scenario, we're looking at 4 Gbps or 500 MB/s. For a 4h long stream that's 7.2TB! of bandwidth, just for one streamer, excluding the viewers on lower quality
mikeryan 3y ago
You can absolutely throw live video on a CDN at which point the bandwidth cost is the same as on demand video. The real-time encoding costs are the real issue.
- goeiedaggoeie 3y ago
  The cache TTL on VOD is significantly higher, so your whole infrastructure needs to have a live origin, which gets hit repeatedly to get the latest fragments/segments from the origin, from multiple edges/midgresses. I find that our origin consumes an order of magnitude more CPU than transcoding and packaging for live once you have even a couple of thousand live viewers and when serving LL-HLS/ll-dash with a low fragment size it increases more. if you are latency sensitive then i between caching layers are not an option.
  - deleted 3y ago
    [deleted]
timr 3y ago
> Can't just throw that on a CDN. You'd be surprised. I have no idea what Twitch does now, but when it was JTV, we had quite a bit of our streaming video on CDNs. We built a complex infrastructure to arbitrage bandwidth. But yeah, if you do it naïvely, you'll hemorrhage money.
- hot_gril 3y ago
  Right, I figured you can place it on a CDN carefully, but it's not nearly as easy as with non-live video which I'd describe more as "throwing" it on there. And even with the complex infra already built, it must be still more expensive to operate. Everything you cache is only good for 10-15s.
  - timr 3y ago
    It's more similar than you might think. The big problem is dealing with the bursty nature of live video -- lots of people will start watching a live event at the same time, which can easily trip you over into expensive bandwidth tier for the peak streams. You need to be able to react in real time and reallocate connections to cheaper providers, shape traffic, use peering arrangements, etc. Static video providers have the luxury of time, and can make these decisions slowly. I forget the exact numbers, but it wasn't totally uncommon for early JTV to burn tens of thousands of dollars on a single stream before we got it under control. Someone starts a stream of a soccer game involving (say) Turkey, and it was like lighting money on fire. The whole event might be over before you could flag the thing down. But like any other form of video, most streams get no viewers, and are relatively cheap to host when you have a scaled infrastructure.
    - hot_gril 3y ago
      Hmm yeah, now that I think about it more, a 1hr stream with 10K viewers is no more bandwidth in theory than a 1hr static video viewed 10K times. But there's what you said about burstiness challenges, which is interesting to read about.
    - k12sosse 3y ago
      Explains why they broke go-live notifications. It's meme-level timely now, sometimes 2-3 hours after they went live.
dvngnt_ 3y ago
I watch 8-12 long videos on YouTube, but I get your point

itsTyrion 3y ago

exactly. Let's assume 1k viewers and 2/3 of them watching on 'source' quality, which is usually 6 mbps. In this scenario, we're looking at 4 Gbps or 500 MB/s. For a 4h long stream that's 7.2TB! of bandwidth, just for one streamer, excluding the viewers on lower quality

mikeryan 3y ago

You can absolutely throw live video on a CDN at which point the bandwidth cost is the same as on demand video. The real-time encoding costs are the real issue.

goeiedaggoeie 3y ago
The cache TTL on VOD is significantly higher, so your whole infrastructure needs to have a live origin, which gets hit repeatedly to get the latest fragments/segments from the origin, from multiple edges/midgresses. I find that our origin consumes an order of magnitude more CPU than transcoding and packaging for live once you have even a couple of thousand live viewers and when serving LL-HLS/ll-dash with a low fragment size it increases more. if you are latency sensitive then i between caching layers are not an option.
- deleted 3y ago
  [deleted]

timr 3y ago

> Can't just throw that on a CDN. You'd be surprised. I have no idea what Twitch does now, but when it was JTV, we had quite a bit of our streaming video on CDNs. We built a complex infrastructure to arbitrage bandwidth. But yeah, if you do it naïvely, you'll hemorrhage money.

hot_gril 3y ago
Right, I figured you can place it on a CDN carefully, but it's not nearly as easy as with non-live video which I'd describe more as "throwing" it on there. And even with the complex infra already built, it must be still more expensive to operate. Everything you cache is only good for 10-15s.
- timr 3y ago
  It's more similar than you might think. The big problem is dealing with the bursty nature of live video -- lots of people will start watching a live event at the same time, which can easily trip you over into expensive bandwidth tier for the peak streams. You need to be able to react in real time and reallocate connections to cheaper providers, shape traffic, use peering arrangements, etc. Static video providers have the luxury of time, and can make these decisions slowly. I forget the exact numbers, but it wasn't totally uncommon for early JTV to burn tens of thousands of dollars on a single stream before we got it under control. Someone starts a stream of a soccer game involving (say) Turkey, and it was like lighting money on fire. The whole event might be over before you could flag the thing down. But like any other form of video, most streams get no viewers, and are relatively cheap to host when you have a scaled infrastructure.
  - hot_gril 3y ago
    Hmm yeah, now that I think about it more, a 1hr stream with 10K viewers is no more bandwidth in theory than a 1hr static video viewed 10K times. But there's what you said about burstiness challenges, which is interesting to read about.
  - k12sosse 3y ago
    Explains why they broke go-live notifications. It's meme-level timely now, sometimes 2-3 hours after they went live.

dvngnt_ 3y ago

I watch 8-12 long videos on YouTube, but I get your point