[opendtv] Re: NAB Showcases Mobile DTV
- From: Tom Barry <trbarry@xxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Fri, 26 Mar 2010 21:05:43 -0400
I'm not sure what everybody means by "monitoring the entire stream" and
why it's bad. I thought the equalizer chips potentially could use a lot
of power, and that's what I was worried about. And decoding the video
potentially can use a fair amount of CPU power. But just demuxing a
transport stream is a fairly light weight task easily done in software
even on 10 year old PC's. I don't see the worry there compared with the
other.
- Tom
Manfredi, Albert E wrote:
> 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.
>
>
>
----------------------------------------------------------------------
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:
