[opendtv] Re: Kennard and Powell to the rescue
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Mon, 12 Jan 2009 22:17:14 -0800
Bob;
If you really want to participate here -- that means saying things beyond
"8-vsb sucks, and nobody will listen to me (anywhere in the world)", it's
best to pay attention.
You merely make an assumption that broadcasters need to transmit MPEG-2
content in the clear (in at least SDTV quality); I think the wording isn't
all that clear on this point, and MPEG-4 content could apply. However, it
would be outside the spirit of the legislation.
Now, we had an exchange about a week ago that answers your first
interlineation below. But, I'll rehash for your "benefit."
The ATSC has divided -- in the most recent version(s) of A/53 and in the
CS/153 document -- transport streams into two concepts: the transport
multiplex and the service multiplex.
The transport multiplex is -- in a nutshell -- 188-byte packets that conform
to MPEG-2 (ISO/IEC 13818, part 1). The service multiplex of A/52 complies
with all of that, with additional constraints.
The challenge in extending the transport and service multiplex is doing it
in such a way that doesn't cause legacy MPEG-2 receivers to barf.
CS/153 (ATSC M/H) has nothing to do with MPEG-2 -- it's actually IP
multicasting of a certain sort -- except that the content is transmitted
over the air in a way that won't cause MPEG-2 receivers to barf.
I should mention that one of the general concepts of MPEG-2 is that
receivers are expected to ignore content that they don't understand.
Basically, ATSC M/H content takes a different path into encoders than does
MPEG-2 content, and (probably; that is implementation details) takes a
different path out of demultiplexers than does MPEG-2 content. The only
place where they co-exist is in the "symbol" layer, which is between the
output of the encoder and the input to the receiver's demultiplexer.
The 'trick' is that after several layers of processing in the encoder, M/H
data is segmented into 188-byte packets that appear to receivers to be null
packets. Simply said, they have the packet_id of 8191 and are 188-bytes in
size. 13818-1 tells receivers to ignore all packets that have the pid of
8191. (There is another way to force MPEG-2 receivers to ignore content, by
setting the transport_error_indicator bit to '1' but that approach doesn't
seem to have been used here.
ATSC M/H receivers know how to look for the content in the null packets and
to process it, and receivers are able to tell, based on encoding, the
difference between M/H packets and good, old-fashioned null packets. They
process the content as M/H content, not as MPEG-2 content.
Doing so in this way means that no change need be made in A/53 to permit M/H
content.
From my memory of reading the IDOV report that analyzed the various schemes
propropsed for M/H, there is only a narrow use case for 1/2 encoding.
Indeed, there are situations -- one has been mentioned here -- where no
guard band interval would overcome the echo interval.
ATSC M/H doesn't seem to require a new exciter or encoder per se; there is
no change in modulation with M/H. PERIOD. It requires a multiplexer, an IP
encapsulator and an new-fangled encoder that outputs combined M/H
encapsulated packets and MPEG-2 packets into a legacy exciter.
"Going with M/H sensibly is the same as starting over IMO."
You don't have a clue, bob. If one transmits M/H content, you still cannot
transmit more than 14.7 (or so) megagits per second of M/H packets. Said
another way, if your transmit the maximum amount of M/H content permitted by
the candidate standard, you will still have at least 4.7 mb/second of MPEG-2
packets. "Might as well use them for MPEG-2 in SDTV."
The plans are that THIS year, there will be 68 m/H transmitters in 22
markets. All this is voluntary, in a horrible commercial environment,
without any government mandate.
Another way of looking at this, Bob, is that ATSC M/H will be eating your
lunch, and the lunch of DVB-T, DVB-T2, and DVB-H. But, and this is
important, much of the "service multiplex" of ATSC M/H is compatible with
the service multiplex of DVB-H. At least a few receiver manufacturers are
promising cell phone-like devices that can receive ATSC M/H, DVB-H, and at
least one will also throw in MediaFlo.
Did I mention that the Service Guide (SG) used in M/H will also work on
Wi-Fi enabled devices, on DVB-H devices, and Media-Flo devices? It's called
OMA-BCAST, and it was developed by the Open Mobile Alliance, with funding
from Nokia and Qualcomm and others. (The Open Mobile Alliance is not to be
confused with the Open Mobile Video Coalition.)
Also -- and this is another key element -- the optional encryption system
used by ATSC M/H is compatible with that used by DVB-H and which can be
offered by MediaFlo.
Note these defintions that come from CS/153:
"Clear-to-Air service - A service that is sent unencrypted, and may be
received via any suitable receiver with or without a subscription.
Free-to-Air service - A service that is sent encrypted, and for which the
keys for decryption are available free of charge."
"Something is happening here, and you don't know what it is, do you, Mr
[Miller]?"
You can try to keep on playing your whiny "woe is me" modulation game.
There are a few elements that still need to fall into place (carrier
interest.) But with ATSC M/H, you finally have something that could
actually create value for your "operational dream" in the U.S. Virgin
Islands.
Note: the modulation wars are over. It's time to "move on" Bob.
John Willkie, who also notes that the first version of ATSC M/H includes an
optional interaction/back channel. And, the Service Guide can be
transmitted via the internet, as well as broadcast, and can be interactive.
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Bob Miller
Enviado el: Monday, January 12, 2009 6:09 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Kennard and Powell to the rescue
On Mon, Jan 12, 2009 at 5:05 PM, Manfredi, Albert E
<albert.e.manfredi@xxxxxxxxxx> wrote:
> Bob Miller wrote:
>
>> Then as I understand it all legacy receivers could receive the
>> signal but not take advantage of the better reception of M/H.
>
> Actually, all legacy receivers receive, but simply ignore, the M/H
> streams. Your confusion is probably caused by the misleading figures in
> A/153.
>
Legacy receivers ignore the M/H streams and therefore can't take
advantage of them. How's that?
> Everything arrives in correctly formed MPEG-2 TS packets. Those with M/H
> headers are ignored by legacy receivers. And the M/H MPEG-2 TS frames
> are carefully spaced so as not to jiggle the legacy MPEG-2 TS frames too
> far out of their expected time slots.
>
>> If they allowed M/H with MPEG4 then they are breaking the
>> rules and making all legacy receivers obsolete.
>
> No. M/H does use what you call MPEG-4. As long as this doesn't break
> legacy receivers, no problem.
>
Wouldn't be more correct to say that M/H can use both MPEG2 and MPEG4
but that legacy receivers cannot use MPEG4? And since the rules say
that the required SD program in the free and clear must be delivered
with MPEG2 that Congress or the FCC cannot allow the required SD
program to be delivered with MPEG4 without changing the rules? If they
change the rules they are making all legacy receivers obsolete. All
legacy receivers would not be able to receive the required SD program
since it is MPEG4.
I am ONLY talking about John's idea of delivering the required SD free
OTA program, nothing else.
If it is ALLOWED then it has to be in MPEG2. To make it really robust
and really useful it would make sense to use 1/4. If you use 1/4,
MPEG2 and M/H I don't think you have room for an HD program in the
remaining 8-VSB bits.
If so every promise of the original plan, the spirit of the transition is
gone.
If you change the codec used for the required SD program you have
changed the whole game and made all legacy receivers obsolete. If you
have done that you might as well start all over. You are already
requiring a new receiver to replace every legacy receiver. You are
already requiring broadcasters to add M/H equipment. Why not just
start over with a far better modulation and codec that would be used
for the entire 6 MHz?
Think of it, if you go with M/H for the SD required program and are
left with a bit starved non HD 8-VSB program why not just use all the
6 Mhz with M/H and MPEG4? How many bits would that give you? Maybe you
could do HD with M/H.
Of course everyone would need a new receiver and modulator and at that
point why not just go with the BEST modulation instead of M/H?
Going with M/H sensibly is the same as starting over IMO.
Bob Miller
> 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.
----------------------------------------------------------------------
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:
