[opendtv] Re: NAB Showcases Mobile DTV

  • From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
  • To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
  • Date: Fri, 26 Mar 2010 19:37:12 -0500

Craig Birkmaier wrote:

> Lazy or just beyond your ability to address since few if any of us
> know how much power these receiver chips will draw. The first gen
> chips we have seen are power pigs. Power cycling is not a huge
> benefit as you must monitor the entire stream to find the segments
> you need.

Surely, Craig, even you should know that "monitor the entire stream to find the 
segments you need" only for a very short time, will not create a big power 
problem. Do read A/153, Part 2, Section 5.2, and see about the Transmission 
Parameter Channel and Fast Information Channel. And show me if anyhting 
mandates constant monitoring of these tables. Look at the "parade repetition 
cycle," and think what it is used for.

Oh, and DVB-H works that way too. Neither of these schemes requires constant 
monitoring of the entire 6 or 8 MHz channel. Only at first, to find your 
subchannel. And when you want to change channels.

> The larger problem is the complexity of the receiver, especially
> the equalizers needed to make this scheme work.

Amazing how they still managed to make the govt converter boxes draw no more 
power than DVB-T SD STBs. I will agree that you might need parts of the tuner 
that to remain alive, to track dynamic multipath.

But anyway, Tom's question brings back something I objected to when A/153 was 
first published. M/H depends heavily on the synchronous MPEG-2 TS link layer. I 
objected to the way M/H has been described in the trade press and even in 
A/153. The claim that "ATSC main channel uses MPEG-2 transport, and M/H uses IP 
transport" sounds too much like politically motivated jibberish. Very 
misleading.

Yes, M/H uses IP overhead to identify packets, but that hardly qualifies as "IP 
transport." In fact, if you really want to get literal about this, "IP 
transport" is at its core a scheme used to allow datagrams, traveling at any 
random interval down a wire, to be dispatched across routers they encounter, 
switched by these routers on an efficient path to their destination. And 
importantly, maintaining any sort of accurate timing between these packets is 
NOT a general IP requirement. At all. It becomes, at best, a difficult 
afterthought, which multiple IETF working groups have tried to accomplish over 
many years, for specialized networks.

Now consider ATSC M/H. The frames NOT sent at any old random interval (they 
very much depend on strict timing), and there are no routers along the way 
anyway. The system is broadcast -- one to all. Not done with IP. IP 
intentionally prevents broadcast across an internet.

The IP part of M/H is almost incidental. The system depends very much on a 
specific type of synchronous link layer, MPEG-2 TS, and builds a synchronous 
frame strucure over that. This is of critical importance to M/H, and it's what 
allows receivers to conserve power. Conversely, M/H only uses IP overhead to 
identify packets. Which it could do just as well with MPEG-2 TS mechanisms.

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