[opendtv] Re: Internet TV distribution architecture
- From: Craig Birkmaier <craig@xxxxxxxxxxxxx>
- To: OpenDTV Mail List <opendtv@xxxxxxxxxxxxx>
- Date: Fri, 10 Jan 2014 12:58:31 -0500
Hi Kon
Glad to see you are still around.
I’m not sure we are talking about the same thing here.
If broadcasters were to offer VOD streams, then yes, colocation with ISPs in
the market makes sense.
IF they are limited to “broadcasting” then they would only need to deliver the
stream for each sub channel to each ISP, as they do today with direct feeds to
many MVPDs (as opposed to the MVPD pulling these bits out of the air.
Are you saying that a single stream per “channel” delivered to the ISP would
not work? If there are issues within the ISP network, would it not be the ISPs
problem to deal with this? Differences in latency within the ISP network would
seem to be minimal as long as the buffers at each customer are kept full. I
don’t think that every customer needs to receive the same bits at the same time.
Am I missing something here?
Regards
Craig
On Jan 10, 2014, at 11:07 AM, Kon Wilms <konfoo@xxxxxxxxx> wrote:
> On Fri, Jan 10, 2014 at 7:30 AM, Craig Birkmaier <craig@xxxxxxxxxxxxx> wrote:
> > On Jan 9, 2014, at 7:52 PM, "Manfredi, Albert E"
> > <albert.e.manfredi@xxxxxxxxxx> wrote:
>
> Why would they need any servers. To replicate their existing business model,
> all they need is one IP Multicast stream per market (or several if they are
> multicasting today). Why would the networks let the local broadcasters stream
> the network feeds AND Offer this content as VOD streams?
>
> Given the fact that every group of subs may have a unique routing path, you
> still have to troubleshoot issues with latency. Bandwidth is no longer the
> issue, but good luck troubleshooting all those hops and fixing latency issues
> out of your control. The only option would be to put edge servers in local
> pops with guaranteed bandwidth, push streams to them possibly over some sort
> of fixed path/tunnel, and make that available via IP multicast.
>
> Current CDNs aren't built for this model. They are most if not all based on
> TCP/HTTP pull.
>
> Plus there is the problem that CDNs share traffic and use infrastructure you
> don't control. The only way to be profitable is to over-provision the
> network. You have no guarantee that a edge node will be able to fulfill your
> content delivery requirements (bandwidth/cpu/storage) if some other customers
> have a huge traffic spike. The larger CDNs just have more boxes in the field.
> But hardware ages quickly these days, so even that becomes an issue with
> failure rates and cost of maintenance. And last if you use a CDN you don't
> get to determine the path traffic flows through it, so you have to design and
> tweak your system around this black box router that may have dozens of
> exceptions to every rule that are out of your control.
>
> For the type of delivery we are talking about, only way to do it is to build
> the CDN yourself.
>
> Cheers
> Kon
Other related posts: