[opendtv] Re: Let the games begin
- From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Wed, 8 Nov 2006 15:24:09 -0800 (GMT-08:00)
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.
Other related posts:
