[opendtv] Re: Let the games begin

  • From: John Willkie <johnwillkie@xxxxxxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Thu, 9 Nov 2006 12:04:15 -0800 (GMT-08:00)

IIRC tends to mean that "I'm not fully sure" so I'll leave it there on this 
thread.

That is the figure I remember, which was just a few MBPS lower than the 
ultimate that DVB-T can offer.  

I did post to this list a few months back a document I wrote the night of the 
presentation that I received.

Indeed, when I tried out my name on Google a few months back, it was the first 
link to come up.  (Draw your own conclusions. :-))

So, "Google 'John Willkie'"

John Willkie

-----Original Message-----
>From: Tom Barry <trbarry@xxxxxxxxxxx>
>Sent: Nov 8, 2006 6:58 PM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: Let the games begin
>
>
>
>John Willkie wrote:
>> 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.
>> 
>
>Are you sure about that?  22 mbps (reliably) in a 6 MHz mobile channel 
>would seem exceptional, and far far better than A-VSB could approach.
>
>- Tom
>
>> 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.
>> 
>> 
>
>-- 
>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: