[opendtv] Re: Twang's Tuesday Tribune (Mark's Monday Memo)
- From: "Kon Wilms" <kon@xxxxxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Tue, 4 May 2004 16:58:35 -0400
> At worst, you can say that the data broadcast concepts were just a
> bit ahead of their time.
No argument from me there. I can't be against this technology if its
the only (well almost) thing I work on, right? :)
> The web is still constrained by bandwidth. I could care less if the
> bits are used by a web browser or an application running in a STB
> that makes them look like a TV channel. What matters is that it is
> possible to deliver an avalanche of bits to receivers that can turn
> them into services.
Thats true for delivering something like TV on the web. But, why would
we want to do that when everyone has a television set? The problems
right now IMHO are with P2P networks. Bittorrent and others try to
solve the problem and do a good job, but there is still the pipe
limitation. However having said that, web-based content is easy
delivered through the existing pipes.
> But more important, the real value of data broadcasting is to serve
> devices that are not tethered to a wired Internet connection.
Thats always been a primary function.
> You know what I mean. Akamai did not move the bits to the edge of the
> network...they moved them closer to the edge. The edge is local
> caching. Combine this with IP multicast and data broadcasting and you
> don't need Akamai.
Ah the fuzzy logic of where does the edge really sit. Many argue that
the edge is the local pop. Edge server devices from Akamai, Skystream,
LII, Novra, et al are not intended for installation at the end user's
location. We can argue this one all day long, but suffice to say its
logical to split it to local edge cache and provider edge cache.
> >>>Emergency
> >>>services can and are being deployed over ATSC.
> >>Can you provide an example?
> >
> >Attempting to be as generic as possible -
> >http://www.cedmagazine.com/ced/2004/0204/02e.htm
>
> Good reference. I think it makes my point.
>
> Clearly data broadcasts can be used to deliver bits both to the
> public and to emergency workers. They wanted to do this in New York
> immediately after 911...but there was no infrastructure in place to
> do it. So they turned to the Internet, and a wireless service
> provider that had gone dark, but still had two-way base stations in
> the area.
That right there is the prime selling point of databroadcast for
emergency delivery - the fact that at 911 the landlines were destroyed.
Databroadcasting from a satellite or dtv station outside the damage
radius combined with a mobile central command functioning as a wifi
rebroadcaster is the way to go.
But this is a specialized application and the data cannot be had over
the internet. I think the same type of application experience is needed
for any type of datacast - you need to give the user something that is
not available via their DSL line, be that high-quality content, unique
content experience, or content experience that is tied to the
programming they are watching.
Cheers
Kon
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
