[opendtv] Re: Internet TV distribution architecture
- From: Craig Birkmaier <craig@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Sat, 11 Jan 2014 13:01:01 -0500
> On Jan 11, 2014, at 11:54 AM, Kon Wilms <konfoo@xxxxxxxxx> wrote:
>
>> On Fri, Jan 10, 2014 at 9:58 AM, Craig Birkmaier <craig@xxxxxxxxxxxxx> wrote:
> Well, there are tens of thousands of ISPs. In many cases a single datacenter
> may house a number of ISPs. And a single ISP may be in multiple geographic
> locations in branches that don't even communicate with each other. So you're
> back to using a CDN/Network.
This specific discussion is about replicating the existing market based model
for broadcasters. I agree that in large urban markets there may be a very large
number of ISPs, but it probably is not necessary to deal with branches in
different markets (geographic locations).
> I'm saying it may prove such a drain on rollout, deployment and management of
> the network as to render the effort unprofitable. If you used fragmented MP4
> you could at least get over some of the hurdles with buffering and latency at
> the expense of every viewer having their live stream delayed between a
> minimum of 30 seconds and max of say 1.5 minutes.
> Also, you're not going to have multicast support unless you implement an
> overlay network to each ISP, or tunnel the UDP through TCP. And for the
> latter, you're going to need equipment to terminate those streams and emit
> them on the ISP network. So you're doing a rollout of at least a half rack of
> gear regardless.
Broadcasters already have direct feeds to many of the cable systems in a
market, which are likely to be ISPs as well. But the idea of colocation at each
ISP may have merit. Would this approach address the latency problems you
describe above?
>
> Probably the best option is to pick large datacenters in each major city
> (Tier4 with blended bandwidth, carrier connectivity that is only 1-2 hops
> from your install, and hooks into multiple if not all ISPs for the local area
> i.e. TWC/Cox/etc), deploy a half rack of gear to each one of those, and push
> streams to those hubs from a central location (or even over satellite where
> possible).
> From there you could build out that small footprint to IP multicast if
> supported, or add more gear for caching to provide streams as HTTP where
> multicast is not available.
This sound like a reasonable compromise.
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?
Regards
Craig
Other related posts:
