[opendtv] Re: (No Date: Tue, 28 Sep 2004 10:30:37 -0400

  • From: Eory Frank-p22212 <Frank.Eory@xxxxxxxxxxxxx>
  • To: "'opendtv@xxxxxxxxxxxxx'" <opendtv@xxxxxxxxxxxxx>
  • Date: Thu, 14 Oct 2004 17:34:57 -0700

From: "John Willkie" <johnwillkie@xxxxxxxxxx> 
To: <opendtv@xxxxxxxxxxxxx> 
Date: Thu, 14 Oct 2004 14:21:06 -0700 

>As to who talks about what here, I am corrected.  (I suspect that you are
>missing a "not" in the last sentence, but I was able to discern a
>correction.)

You're right. I meant to say you are NOT the only one who has publicly 
discussed the influence of patents and IP licensing in the various modulation 
wars that have been fought as far back as the 1920s.

>But, how much do those COFDM silicon assemblies that handle HD cost compared
>to 8-VSB?  Shouldn't we compare apples to apples?

HD has nothing to do with it. Either modulation scheme can carry enough 
megabits per second in 6 MHz to support HDTV. What you should be asking is 'how 
much does a COFDM demod cost compared to an 8-VSB demod'? The difference in 
silicon area between the two is quite dramatic. So is the power dissipation. 
Silicon area directly goes to cost, but power also indirectly affects cost 
because a power-hungry IP core limits the level of integration that is 
achievable in an SoC.

Bert is fond of invoking Moore's Law to argue that in time, the cost 
differences due to silicon area between COFDM and 8-VSB will be in the noise. 
But Moore's Law doesn't apply to power dissipation. In fact, the power problem 
keeps getting worse as CMOS geometries continue to shrink. The desktop PC 
solution to this problem -- a massive heatsink & fan -- will never fly in the 
CE world.

Cost has both a silicon component and a licensing component. Even if we give LG 
the benefit of the doubt and say their terms will be about the same as the DVB 
licensing terms, 8-VSB still has a cost disadvantage.

>As to permitting COFDM would not have required any change in PSIP:  I guess
>I have an unfair advantage, being that I only really know about metadata.
>However, I've looked extensively at the DVB-SI spec, and I know PSIP and
>PMCP innately.  If you can find a way to unambiguously define a COFDM
>transport stream in PSIP or PMCP, could you point me to it?  If you know of
>a way to unambiguously define an ATSC transport stream in DVB-SI, you might
>want to point me to that.

What do you mean a "COFDM transport stream" or an "ATSC transport stream"? Both 
ATSC and DVB-T use MPEG-2 transport streams. Even with a non-8-VSB modulation 
scheme, the transport parser, video decoder, audio decoder, PSIP processor, 
etc. would see the same 188 byte MPEG-2 TS packets that they see now from an 
8-VSB demod. You're getting hung up on differences between ATSC & DVB-T 
regarding what goes into those TS packets, and I'm saying those contents 
wouldn't have to change just because the modulation was (hypothetically) 
changed. A "COFDM ATSC" system could still be ATSC in every respect, except for 
the modulation.

But of course this is all water under the bridge. The decision was made and so 
we move on and make the best of it. But that doesn't mean we can't look back 
and speculate about how things might have been different if it had gone the 
other way.

The real irony is that two of the reasons COFDM was rejected by ACATS were (a) 
it was believed it was still in the R&D stage, not yet ready for deployment; 
and (b) it was believed that the large FFT sizes would require too much silicon 
to make a cost-effective solution. Considering the earlier and still much 
larger volume shipments of DVB-T receivers relative to ATSC receivers, and 
considering the dramatically smaller silicon area & power of DVB-T demods vs. 
ATSC demods, points (a) & (b) above turned out to be 180 degrees out of phase 
with reality.

-- Frank
 
 
----------------------------------------------------------------------
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:

  1. Home
  2. opendtv
  3. Archive
  4. 10-2004