[opendtv] Re: Let the games begin
- From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Wed, 8 Nov 2006 18:32:16 -0800 (GMT-08:00)
IIRC, they're offering 16-20 linear video (each with two audio) program
services, plus 'clip channels' and a handful of audio and data services in a
multiplex that occupies a 6-mhz channel using 22 or so MBPS per mux.
In strong signal areas, the frame rate is 24 or 30 per second; otherwise, it's
12 to 15 per second. But, remember that those video channels at best are half
the resolution of NTSC, but with image sharpening technology.
Remember: people don't watch technology, and they tend to seek quality when it
is available and has a wide variety of content. (This includes the betamax
argument, since it wasn't widely available and had limited variety of content.)
John Willkie
-----Original Message-----
>From: Tom Barry <trbarry@xxxxxxxxxxx>
>Sent: Nov 8, 2006 5:22 PM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: Let the games begin
>
>
>
>John Willkie wrote:
>
> > What is confusing to you here, Tom? Qualcomm is offering (or will be
>within a few months or a year or whenever) 1.5 mbps video mobile video
>channels 320x240. For $15 per month. It's highly likely that A-VSB
>services will (start out at least) as free to air. Guess which one will
>win out on that ground?
> >
>
>To me it's just bits, like Craig says. Let's call it bits/second/Hz,
>the spectral efficiency. That is, at a reasonable, typical, and
>equivalent (very bursty, non-random) error rate, how many bits per
>second can be delivered in how much channel bandwidth by the various
>methods? For instance, what size channel (in MHz) is Qualcomm using for
>that 1.5 mbps premium service?
>
>Or how much would they take if they wanted 4.5 mbps like A-VSB? (close
>to enough to do scaled 540p HD just fine, competing with today's typical
>OTA quality)
>
>- Tom
>
>
>> What is confusing to you here, Tom? Qualcomm is offering (or will be within
>> a few months or a year or whenever) 1.5 mbps video mobile video channels
>> 320x240. For $15 per month. It's highly likely that A-VSB services will
>> (start out at least) as free to air. Guess which one will win out on that
>> ground?
>>
>> Have you ever considered the size of screens that will be most commonly used
>> for mobile video? Let's say for the time being that few to none will be
>> 1080x1920, or even 1/5th that size. Probably for a very long time ...
>>
>> I would think that A-VSB mobile video will be mutually exclusive (on the
>> same transport) with HDTV, and probably will be mutually exclusive with data
>> broadcasting. (I can't say why at this point.) It's just another arrow in
>> the increasingly flexible ATSC quiver.
>>
>> One also needs to consider the ability to offer an "associated small screen
>> service" as hierarchical video. In other words, where some of the mobile
>> video is usable in fixed locations to augment the main video service. These
>> are application-layer issues: first the transport-layer issues need to be
>> resolved, which are "probably" being addressed as I write.
>>
>> The latest revision of the A/53d (dtv) and A/65c (PSIP) specifications
>> already contemplate associated or free-standing video services.
>>
>> John Willkie
>>
>> -----Original Message-----
>>
>>>From: Tom Barry <trbarry@xxxxxxxxxxx>
>>>Sent: Nov 8, 2006 8:17 AM
>>>To: opendtv@xxxxxxxxxxxxx
>>>Subject: [opendtv] Re: Let the games begin
>>>
>>>
>>>
>>>Craig Birkmaier wrote:
>>>
>>>
>>>>Let the games begin.
>>>
>>>Is A-VSB still in the game?
>>>
>>>It appears that after FEC overhead in order to get mobile or good multi
>>>path reception it would only have 4-5 mbps of payload. Did I understand
>>>that correctly? If so then it obviously doesn't do anything for HDTV
>>>reception since with MPEG-2 that is certainly not enough for HD.
>>>
>>>But I guess A-VSB is really only for mobile. Can anybody say what
>>>throughput can be expected for mobile reception on a 6 mhz channels
>>>using the various DVB or OFDM options? Is A-VSB competitive here?
>>>
>>>I guess most telling (for 8-VSB HDTV) is the quote from (Samsung's?)
>>>Mike Simon about 17 minutes into the audio stream about possible
>>>receiver side improvements to 8VSB:
>>>
>>>---- quote -----
>>>... To give you just a flavor for what we have and what we can have with
>>> this proposal and why it does make a difference, graphically if you
>>>can look at this it's kind of intuitive. Here's the normal 8-VSB
>>>physical layer as I show on my left here, and it shows it's one data
>>>frame made up of 2 data fields and it has a PN511 and other PN sequences
>>>that occur in this data field sync area, but that only occurs every 24
>>>milliseconds, so, if I want to be able to track anthing that's changing,
>>>it better be changing awfully slow. Or I'm not going to be able to
>>>track it and, uh, as good as blind equalization techniques have been,
>>>and I guess will even be, uh, you know, we don't, SAMSUNG DOES NOT
>>>BELIEVE THAT RALEIGH CHANNEL PERFORMANCE WILL EVER HAPPEN BY JUST
>>>RECEIVE-SIDE ONLY IMPROVEMENTS. [emphasis added]
>>>---- /quote ---
>>>
>>>Is Raleigh channel performance something we need in gen-x receivers to
>>>handle dynamic multi path properly?
>>>
>>>- Tom
>>>
>>>
>>>
>>>>At 5:54 PM -0500 11/7/06, Allen Le Roy Limberg wrote:
>>>>
>>>>
>>>>>In the EVSB, ASB, Philips and ETRI proposals the information content is
>>>>>coded in such a way that it is not possible for legacy receivers to
>>>>>decode
>>>>>it. This means information content has to be transmitted twice if legacy
>>>>>receivers are to receive it and new receivers are to receive it with full
>>>>>robustness. This is a major waste of code capability.
>>>>>
>>>>>The original goal in the Request for Proposals from ATSC was to ruggedize
>>>>>HDTV broadcast or multi-cast SDTV. The various proposals seem to
>>>>>focus on
>>>>>replacing HDTV with other services that halve or quarter code rate.
>>>>>Perhaps
>>>>>this is a tacit concession to business opinion that HDTV broadcast and
>>>>>multi-cast SDTV will disappear from terrestrial transmitter service.
>>>>>
>>>>>Al
>>>>
>>>>
>>>>Thank you Al for beginning a discussion that I hope will help legitimize
>>>>our community - by this I mean that we may be able to contribute
>>>>solutions, rather than observing and analyzing the DTV transition. I
>>>>believe that one objective of the OpenDTV community is to help turn the
>>>>vast wasteland of Digital TV in the U.S.A., into a critical piece of the
>>>>infrastructure for communications in the rest of this new century. By so
>>>>doing, we may also contribute an acceleration of the DTV transition
>>>>globally.
>>>>
>>>>So here we are, a decade into the DTV non-transition in the U.S., and we
>>>>are trying to invent ways to layer complexity onto a standard that was
>>>>never designed to do many of the things that now seem important to the
>>>>folks making business decisions about the future.
>>>>
>>>>As a starting point for further discussion, I would suggest that
>>>>everyone who wants to contribute, take a look at a recent presentation
>>>>about the A-VSB proposals, at the Iowa DTV Symposium, put together by
>>>>the "original" IPTV people, Iowa Public Television.
>>>>
>>>>http://www.iptv.org/dtv/2006/media_pres.cfm?ses=5&id=7&Track=T
>>>>
>>>>This page contains an Adobe flash file with the presentation slides, and
>>>>a downloadable MP3 file with the audio from the session. It's almost
>>>>like being there...
>>>>
>>>>;-)
>>>>
>>>>I have reasons to believe that the Chairman of one of the ATSC working
>>>>groups working on and helping to test these proposals will be addressing
>>>>some of the questions that Bert raised about the mobile tests in
>>>>Buffalo. At least Mr. Aitken said he was working on a response when I
>>>>talked with him Tuesday.
>>>>
>>>>Both Al and Bert have focused some attention on the issue of the payload
>>>>overhead that may be required to utilize the new tools that are being
>>>>proposed. The presentation covers some of the trade-offs and provides
>>>>an example of the overhead needed to support the training sequences and
>>>>a robust 1.5 Mbps service. Mr. Aitken noted in our conversation, that
>>>>they are just starting to test these tools in the real world, and it is
>>>>still too early to know how to optimize their use and determine to
>>>>actual overhead.
>>>>
>>>>Needless to say, there is plenty here to sink your teeth into, and to
>>>>generate serious discussions.
>>>>
>>>>But these discussions cannot take place, without also considering the
>>>>alternatives.
>>>>
>>>>I have just completed a column on the Digital LPTV transition in the
>>>>U.S. There were thousands of applications for digital licenses for Class
>>>>A, LPTV and TV translators, and the FCC will begin to issue licenses
>>>>next year. This industry has the unique opportunity to develop its own
>>>>platform for DTV and to build SFNs from the ground up. They are
>>>>questioning whether they should be saddled with legacy ATSC, help drive
>>>>A-VSB deployment, or simply join Qualcomm and others, who are deploying
>>>>OFDM solutions in former TV spectrum.
>>>>
>>>>The FCC has not authorized the use of OFDM by these low power
>>>>broadcasters, however, the airwaves will soon be carrying OFDM
>>>>broadcasts that will be received by devices being used by U.S.
>>>>consumers. One can build a very strong argument to let these licensees
>>>>have the flexibility to choose the technical parameters of their
>>>>infrastructure as Sinclair proposed for full power DTV broadcasters.
>>>>
>>>>And there is still another alternative.
>>>>
>>>>START OVER
>>>>
>>>>There is plenty of precedent for this - most notably, NTSC.
>>>>
>>>>As was the case when RCA brokered the NTSC deal, it need not take a long
>>>>time to come up with a viable solution. So ultimately, this discussion
>>>>should also consider how the tools that we have today could be used to
>>>>create a digital terrestrial broadcast network that is:
>>>>
>>>>Interoperable, Scalable and Extensible, but most important, economically
>>>>viable and able to drive innovation and new services in the future.
>>>>
>>>>Let the games begin.
>>>>
>>>>
>>>>
>>>>
>>>>----------------------------------------------------------------------
>>>>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.
>>>>
>>>>
>>>
>>>--
>>>Tom Barry trbarry@xxxxxxxxxxx
>>>Find my resume and video filters at www.trbarry.com
>>>
>>>
>>>----------------------------------------------------------------------
>>>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.
>>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> 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.
>>
>>
>
>--
>Tom Barry trbarry@xxxxxxxxxxx
>Find my resume and video filters at www.trbarry.com
>
>
>----------------------------------------------------------------------
>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.
>
----------------------------------------------------------------------
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:
