3 ms·

> 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 CD

by 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.

by timr 3y ago

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.