[opendtv] Re: Internet TV distribution architecture
- From: Craig Birkmaier <craig@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 23 Jan 2014 14:06:13 -0500
Thanks for the feedback Kon.
We are starting to watch some shows on Netflix. These seem to connect quickly -
typically about 10-15 seconds - which I assume is just filling the local
buffers. I was also surprised how responsive Netflix is when searching in fast
forward. My cable DVR is pathetic in terms of searching - they obviously want
us to see enough of every ad to keep advertisers happy...
Regards
Craig
> On Jan 23, 2014, at 11:33 AM, Kon Wilms <konfoo@xxxxxxxxx> wrote:
>
> 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
>
Other related posts: