[opendtv] Re: Thomson readies solutions for U.S. Digital TV broadcast transition
- From: "Allen Le Roy Limberg" <allimberg@xxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Sat, 13 May 2006 11:28:22 -0400
A-8VSB has a number of proposed uses beyond trying to intrude a new and more
robust data pipeline into the ATSC 8VSB signal. A-8VSB introduces known
symbols into the auxiliary fields of packets in the MPEG-2 transport stream.
The trellis coding system in the original 8VSB signal standard does not have
predetermined parity bit at start of data fields. An aspect of A-VSB is
solving this problem.
A-8VSB can also be used to insert known symbols periodically into data
fields to provide additional training signals for the adaptive equalizer to
improve performance under dynamic multipath conditions. I am unaware of any
effort having been made to determine whether this is better than four- or
five-thousand-symbol signature analysis using DFT techniques for handling
dynamic multipath, as proposed some years ago by Doug McDonald, the patent
for which should soon issue. Doug's technique does not chew up data
capacity or intrude into packet structure like A-8VSB would.
E-8VSB and A-8VSB have some similar problems in trying to intrude a new and
more robust data pipelines into windows in conventional MPEG-2-compatible
data packets. There is over 10% overhead for the headers and R-S parity
bytes of those packets. The systems were developed by receiver designers,
who pretty much ignored transmitter and broadcaster problems in providing
the more robust data pipelines.
The problems of how to assemble programs that combine ordinary MPEG-2 data
and robust data have been ignored by the receiver designer types of
engineer. Little or no thought has been given to ad insertion, switching
between local and remote sources of program material, etc.
The transport stream multiplexers for both systems involve many, many data
packets. Providing suitable transport stream multiplexers is a formidable
impediment to transmitter design. Any practical robust transmission scheme
needs to replace small groups of data segments with chunks of robust data
which chunks are independent of each other.
The original request for proposals issued by ATSC had looked for a
backward-compatible robust transmission scheme that would "put training
wheels" on the existent 8VSB data packets. E-8VSB and A-8VSB do not beef up
the existent 8VSB data packets, but displace them with different independent
transmission schemes. So long as legacy receivers could continue to receive
the reduced number of remaining 8VSB data packets without disruption, many
pretended that the goal of backward-compatibility was met by a proposal such
as E-8VSB.
E-8VSB cuts code rate to one half or one quarter of original 8VSB code rate.
This means that you cannot transmit 720p HDTV in robust format. Many then
pretended that transmitting just audio and maybe some critical data in
robust format was okay. The whole concept of transmitting robust data
independent of HDTV programming began to emerge when no proposal was made to
cut code rate less severely and accept whatever most improvement that would
be available to HDTV reception. The somewhat definite original business
plan to gather more eyeballs for the principal broadcast was apparently
abandoned, and no definite new direction has been forthcoming from ATSC.
I had been looking at the original "training wheels" concept using half code
rate when Bert Manifredi commented that a (16, 8) linear block code seemed
like a lot of overkill on coding. Glenn Reitmeier at NBC advised that
broadcast engineers would be very reluctant to ever accept halved code rate,
even if legacy DTV receivers could usefully receive the robust
transmissions.
It seems to me now that the original "training wheels" concept can be
implemented without a great deal of difficulty for 720p HDTV, by reducing
8VSB code rate only a third using (12, 8) linear block coding of each data
byte in the 207-byte Reed-Solomon codes. This means each pair of data
segments containing MPEG-2-compliant data packets is accompanied by a
segment of (12, 8) LBC parity bits. A transport stream multiplexer that
opens holes for segments of parity bits is relatively easy to design. The
(12, 8) linear block coding can correct some data bytes, but also locates
errors for the 207-byte Reed-Solomon codes. Error location permits the use
of a known alternative RS-decoding algorithm that doubles the
error-correcting capability of the (207, 187) RS codes to 20 bytes per
codeword. The (12, 8) linear block coding I have contemplated is Gray
coding followed by shortened (15, 11) Hamming coding followed by Gray
decoding, which would actually be implemented in ROM.
Maybe someone can suggest better "training wheels" coding that reduces 8VSB
code rate only a third. But IMHO "training wheels" coding sure looks like a
more promising route to follow than trying to pack a new data stream into
windows in MPEG-2 packets.
Al Limberg
----------------------------------------------------------------------
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:
