[opendtv] Re: ATSC Mobile DTV
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Tue, 6 Jan 2009 11:24:01 -0800
Incomplete:
"The Packet Formatter is the last process in the M/H pre-processor." Is the
sentence before the one you cited.
"place holder" is a give-away.
And, that was at the end of 15 pages on the M/H preprocessor, which cannot
accept MPEG-2 packets as input, and must have 188-byte packets as output to
be able to multiplex them into the main transport stream, after it has
underdone about five levels of pre-processing and data de-interleaving.
I've checked; that's the only reference to pid in any of the cs documents.
Which begs the question - unanswered here - what the packet id (for
transmission) of MH data, and whether users will ever be presented with
packet ids for MH packets.
To the first question, I can only say that the language has changed during
the drafting and editing process so that the pid used is not mentioned, but
it's the "obvious" choice to send information that would only confuse an
MPEG-2 demultiplexer. From what I read, the only way to implement this at
receivers is to have a M/H demux that outputs, as appropriate, an M/H stream
and a MPEG-2 stream.
Indeed, it's not obvious in the cs documents, nor does it need be, but the
only MPEG-2 style information in these M/H packets is the sync byte and the
pid. So, it's not even a full MPEG-2 packet header, but a subset. Any
MPEG-2 decoder exposed to this data form will not be able to begin to
process the packet payload. Even if it did so without a continuity_counter,
it wouldn't be able to make any sense of the data, since it would have to go
through sccc/pccc, error correction, and sucvh.
Bert was looking for a thin reed to place his hopes of watching ATSC M/H
content on legacy tv sets, Ron. You gave him a thin one.
In simple math, the payload of an MPEG-2 packet is 184 bytes. The payload
of an ATSC M/H packet - at the level being discussed in the text you cited -
is 185 bytes, unless I missed something. And, it must be noted, this
processing path is not something that MPEG-2 packets will be exposed to.
I tend to know not enough about section 2, Ron, but I won't ever confuse a
188-byte packet with only a sync_byte, a packet id, and 185 bytes of
payload, traveling on the null pid with a valid MPEG-2 packet. How about
you?
John Willkie.
_____
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Ron Economos
Enviado el: Tuesday, January 06, 2009 3:27 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: ATSC Mobile DTV
The packet formatter next shall replace the 3-byte MPEG header place holder
with an MPEG
header having an MHE packet PID.
Ron
John Willkie wrote:
More foolishness.
MPEG-2 is a specific form; the mpeg-2 packet; one sync byte, three heaer
bytes, optional adaptation field, and payload. The only thing that M/H has
with this is the packet size of 188 bytes. It's simply absurd to aver that
M/H is being carried over MPEG-2 ts, since an MPEG-2 ts requires the packet
form, not just the 188 byte length.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de Manfredi, Albert E
Enviado el: Monday, January 05, 2009 3:19 PM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: ATSC Mobile DTV
Mark Aitken wrote:
The A/153 Candidate Standard has been published on the ATSC
Web site. See:
http://www.atsc.org/standards/candidate_standards.php
Very interesting. I have a few preliminary comments, some of which I
might adjust after having digested this longer:
1. Not sure what made this more desirable than A-VSB. Without an
equivalent document for A-VSB, from which to compare details, the two
seem functionally very similar. Both layer an additonal 1/2 rate and/or
1/4 rate convolutional code on top of the legacy 2/3 rate, to lower the
required C/N margin, and both introduce additional training sequences to
expedite receiver sync and improve performance with dynamic echo.
2. I didn't find any table quantifying the C/N margin requirements in
the different M/H modes. Would be nice to include such info in Part 2,
Tables 6.1 and 6.2, for instance.
3. I quibble with Figure 4.1 of Part 2, and similar ones in other parts
(Figure 4.3 of Part 3), which show that ATSC legacy is carried over
"MPEG-2 Transport," whereas M/H is carried over "IP Transport." Both are
carried over MPEG-2 TS frames. M/H has an added IP layer on top of that,
but in truth, the IP and UDP layers are only used to identify packets.
There's no actual IP routing going on here. It's broadcast. So M/H
service is encapsulated within MPEG-2 TS, just like legacy ATSC service,
and there are additional link layer functions added for the MH Ensembles
(see Figure 5.2 of Part 2). In a (one way) broadcast environment,
essentially the functions of the network, transport, and session layers
become rather trivial. I mean, for example, can I support a single M/H
service using the facilities of multiple non-synchronized, TV
transmitters, as one can do with a single TCP/IP or UDP/IP session using
multiple underlying layer 2 networks and multiple different routes?
(Meaning, I'm not talking about fancy link layer tricks, akin to
Ethernet link aggregation, but rather basic routing of IP datagrams
independent of the underlying networks.)
4. On a similar note, I quibble with the mention of RTCP, e.g. Fig 5.3
of Part 1. Only part of RTCP functionality is used here. QoS is provided
entirely by the carefully built, time divided, synchronous, link layer
of M/H, all of which occurs "underneath" the IP and UDP layers. QoS is
not provided by any feedback signaled by RTCP to the source of a
transmission, as RTP/RTCP are expected to operate. This is the crux of
my disagreement with the layered model as shown here. RTP/RTCP are
specifically written to NOT depend on a synchronous link layer. Whereas
M/H cannot function without the M/H synchronous link layer.
5. Leaving aside the OSI layer quibbles, I got a real kick out of
Section 7.5 of Part 3. Some months ago, I posted a sketch of a "true"
broadcast cellular service, in which each translator in the
multi-frequency network would transmit the frequencies of adjacent
cells, to allow receivers to seamlessly switch from one tower to the
next, as the signal from a new tower becomes stronger than the previous
tower's signal. Lo and behold, that's already supported in M/H, on a
program by program basis. A "no apologies" cellular broadcast network.
6. Also enlightening is Section 6.1 of Part 2, which shows that M/H
service can take increments of data rate away from the main ATSC service
as low as 130 Kb/s. Tables 6.1 and 6.2 of Part 2 show that if M/H takes
up 0.917 Mb/s of a 19.39 Mb/s multiplex, it can provide a 1/2 rate M/H
channel of 312 Kb/s, and the added training, framing, etc. takes up the
remaining 147 Kb/s. Or half that payload data rate if all groups are set
to 1/4 rate.
7. So, let's compare this to DVB-T HM. We don't know the C/N margins, so
the comparison is not very meaningful, but let's look at this anyway. If
we take a 4.58 Mb/s chunk out of the 19.39 Mb/s main channel, it can
provide as much as 1.58 Mb/s of 1/2 rate robust channel, or half that
much for 1/4 rate.
In DVB-T, 6 MHz channels, a 1/2 rate QPSK HM channel provides about the
same robust bit rate capacity, with C/N margin in gaussian channels of
8.9 dB, if you want the rest of the channel to be used in 64-QAM mode,
comparable to the M/H case.
My bet is, these two are similar, however M/H also offers a 1/4 rate
option. But without the C/N margins, hard to tell. Also, an advantage of
doing the robust channels this way, vice changing the constellation as
HM does, is that you can fine-tune just how much you want to take away
from the main channel. (For example, a single 312 Kb/s robust stream
only tales 0.917 Mb/s away from the main channel.)
(Sidebar: A-VSB, using the 1/4 rate and turbo code, managed ~4 dB C/N
margin, with a single receive antenna. Don't know what the 1/2 rate
robustness was, but a 9 dB C/N margin comparable to DVB-T HM does not
sound out of the realm of possibilities.)
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: