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