Didn't see this one - On Sat, Jan 11, 2014 at 10:01 AM, Craig Birkmaier <craig@xxxxxxxxxxxxx>wrote: > One more question about live streaming. I have been using the Watch ESPN > app this year to view live football games; and I sometimes watch live > events like Apple keynotes. It typically takes between 20 and 60 seconds to > join these live events. Do you know if these are IP Multicasts, or if they > are individual streams per viewer? > As far as I know it's all Apple HTTP Live Streaming or similar fragmented MP4 delivery over HTTP (Smooth Streaming, HDS, etc.). These protocols work great for VOD delivery where you have ample cache, but fail miserably at live media distribution for massively geo-dispersed audiences. In my experience the large CDNs also suck at delivering this type of content. First most times they don't even know how to get the job done, and second you have to expire the fragments quickly (thus defeating the purpose of a buffer) and load balance CDN nodes by hashing on something other than simple client IP (thus defeating the purpose of scaling horizontally). You get around some of these problems by increasing chunk and thus packets per chunk. But that means you see ~1 minute delays for live streams. And it means it takes longer to distribute the chunks. And we haven't even gotten to the fact that more chunks need to be expired faster from in-memory cache, thus defeating the purpose of your caching layers. Low latency simply can't be done through a CDN, and to boot HTTP direct from origin with as few frags per chunk as possible latency (while still keeping the system working and not rebuffering constantly) is ~ 15+ seconds typically (since you need to cache the fragments on your own network to scale the delivery). Anyone claiming otherwise with HTTP streaming is probably fibbing or is serving you content off a single server. Cheers Kon