[opendtv] Re: Twang's Tuesday Tribune (Mark's Monday Memo)
- From: Craig Birkmaier <craig@xxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Tue, 4 May 2004 15:25:35 -0400
At 11:11 AM -0700 5/4/04, Kon Wilms wrote:
> >I never denied it. But the press release you cited had nothing to do
>with satellite distribution directly to viewers...it was a backhaul
>agreement.
>
>So Echostar was providing backhaul?
No, this was the later effort I was talking about when you said I
finally admitted my mistake.
>
>Here's an interesting analysis of why they failed (see the reference to
>beating Moore's Law - applies to the increase in speed of landline broadband
>too, as well as the failure of their GeoBox)
>http://gradcenter.marlboro.edu/~dmaynard/foundations/geocast_evaluation.html
>
>And here's a press release for their use of Echostar (NOT for backhaul like
>you keep saying - like I said they changed business plans faster than I
>change underwear -- cable, dbs and dtv were their intended distribution
>platforms)
>http://www.broadbandweek.com/news/0011/0011_news_geocast.htm
What has this press release got to do with the first press release
about the Geocast Deal with GE American Communications (GE Americom)?
Don't bother to answer. Geocast could not get a terrestrial business
off the ground. Before they went under they tried to map the business
model to a different (DBS) distribution infrastructure.
By then it was too late. I might add that Echostar was not able to
compete against cheaper wired broadband networks...
>
>Your opinion is not fact, fortunately.
>
>>>
>>>>with a multi-channel DBS service it might fly...
>>>
>>>Well it wasn't, and it isn't, and it failed, so moot point.
>>Yes it failed for all the reasons we have been discussing.
>
>Echostar isn't a multi-channel DBS service? Thanks for proving me right.
This proved nothing. Both DirecTV and EchoStar are bringing back data
broadcasting now that they have a large installed base of subscribers
with local caching capability in the STB. This was not the case when
GeoCast tried to team with Echostar - that business model was to
deliver bits to PCs to get around the bandwidth constraints of
broadband networks for big media files.
At worst, you can say that the data broadcast concepts were just a
bit ahead of their time.
>The web is non-linear. No-one wants web content over databroadcast links.
>Everything you list can be had by opening a web browser - so none of them
>are killer applications. And none of them will convince a company to roll
>out a service or potential users to pay extra for it.
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.
The concepts are valid and they are beginning to gain real traction
based on two realities;
1. You need local cache to make any data broadcast model work;
2. You need a STB with enough local image processing capability to
run applications that can turn bits into services.
Those conditions are now being met.
But more important, the real value of data broadcasting is to serve
devices that are not tethered to a wired Internet connection.
>
>>This is not a discussion about cool technology. It is a discussion
>about the actions of entrenched players who are working overtime to
>extend the life of a dying legacy product, while simultaneously
>slowing the evolution to new, more effective ways to enhanced digital
>communications.
>
>I must be missing something since we've worked on systems for some of those
>'entrenched players' and a lot were abandoned due to no revenue model being
>present. Who exactly are these entrenched players?
Nothing new here. You know who I am talking about. And you also know
that they have made small investments in this area for the specific
purpose of understanding the territory, and making bold public claims
that there is no revenue model. We put the guy who developed ABCs two
screen interactive TV venture on the cover of Digital Television a
few years ago. he got fired because it made it look like there was a
revenue model there.
>
>I don't know how to even respond to that one. So they solved nothing but
>solved the infrastructure limitations. They provide edge caching servers but
>they will go away when caching moves to the edge. Err, ok.
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.
>
>>>ITFS is not being used for datacasting.
>>Correct it is being used to deliver linear analog video content to
>analog VCRs, where the content is cached for later playback...same
>concept using legacy technology.
>
>Haha so now a VCR is a content cache? Wow, you are stretching yourself
>pretty far on that one for an excuse to legitimize your wild claims. :)
Of course a VCR is a content cache. This is no different that telling
a Tivo to record channel 21 at 7pm. Many school districts have
libraries of content available to teachers. The teacher can schedule
a "download" with the central library; it's their responsibility to
program the VCR to catch the scheduled broadcast via the ITFS system.
It happens everynight, all over America.
>
>>>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.
Peace!
Regards
Craig
----------------------------------------------------------------------
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:
