[opendtv] Re: Internet TV distribution architecture
- From: Kon Wilms <konfoo@xxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 23 Jan 2014 11:38:02 -0800
The Roku has special support for FF/RW in the form of sets of images that
get generated from the video. So in essence your FF/RW is downloading
thumbnails. :-) Only when you seek to a point does it do a video request.
And if you have sufficient bandwidth, filling that local buffer is pretty
quick since the VOD fragments cache great on any CDN.
Downside is that there are hundreds of thumbnails per title. Caching the
small thumbs is also the engineering challenge (Youtube had this problem in
their infancy).
Cheers
Kon
On Thu, Jan 23, 2014 at 11:06 AM, Craig Birkmaier <craig@xxxxxxxxxxxxx>wrote:
> 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: