At 4:31 PM -0500 11/24/10, Albert Manfredi wrote:
Even Kon noticed that data broadcasting is usually met by a big "who cares" shrug. But more to the point, and we've been over this too many times, data broadcasting is not TCP/IP. It requires some sort of carousel, aside from the basic FEC on the fly. So this immediately violates one of Tannendwald's notions, i.e. not to repeat stuff over and over. With the data carousel, you can tolerate occasional dropouts, but you are wasting bandwidth unless you can justify the waste by a huge population of interested receivers.
Sorry, but Peter was talking about the inefficiency of using the two-way data networks for unicasting the same content over and over again:
The principal cause of the shortage problem is the architecture of first-decade technology, where each user's request for content generates a separate digital stream in response. One way to solve the capacity problem is to drive more traffic to wired systems, a seemingly unpopular option with the unwired generation. Another is to deliver frequently used content only a few times instead of every time viewing is requested. That is exactly what broadcasting does: it efficiently distributes content over a stream that occupies the same amount of spectrum no matter how many people use it. The only thing that is different about today's demand for video content is the desire for time-shifting, which is becoming easy to accomplish, without using more spectrum, by storing and replaying content in the user's device. That is what DVRs and advanced set-top boxes do today, with cellphones and portable tablets not far behind.
There is no way to interpret this as unicasting Bert; that is what peter says is the problem. He IS talking about periodically sending content to local cache using a carousel as you describe.
So once again, a big stick supported by low power DOCRs is doable, even with ATSC, to make reception easier, without incurring the inefficiencies of true SFNs. Combined with data carousel, such a system would work without having to pay the price of a two-way infrastructure. If broadcasters find some killer app that makes it worth their while, they could go this route immediately, with no excuses, no new standards to ratify, and no make-believe insurmountable problem with the infrastructure.
I think we are closer to agreement here. The real issue is spectral reuse in congested areas, where SFN's can be used to increase spectral reuse and to tightly define local markets. The big stick will still have their place is less congested areas...
But we've been through all of this ad nauseam. 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.