[opendtv] Re: LG launches 6th gen ATSC digital TV broadcast receiver chipset

I claim no expertise in PSIP, but I offer the following:
- The fact that something takes a long time getting through ATSC (or doesn't get through at all) need not have anything to do with its complexity. I worked for years on the extremely simple change to allow 720h to be phased in.
- Whatever problems there are or are not with the standard, I intentionally tried tuning in channel 22 (which was carrying A-VSB) during the convention. On no set that I tried was there any noticeable PSIP problem.
I would not deny that there might not be SOME receiver out there that would have a problem, but, at the pre-NAB PBS Technology Conference, it was said that there are receivers that cannot handle 448 kbps AC-3, even though that IS allowed in the standard. 

TTFN,
Mark


John Willkie wrote:

I am not privvy to the latest deliberations of  t3/s8, but can say that
there's not a simple wording issue that will permit A-VSB compatibility with
PSIP.

Just look at the timeline: A-VSB was proposed to ATSC circa May 2005.  It
still hasn't reached the candidate standard status.  Sounds like
not-so-simple issues are involved.

The initial idea of R-S and Samsung was to require all packets to have
training signals in the adaptation field.  This would have required "mere
change" in the A/65  text that forbids adaptation fields in packets carrying
PSIP packets.  Sounds simple.  But, it would have broken every encoder and
decoder on the marketplace; it wasn't backwards compatible.

ATSC A/53 (incorporated by reference by the FCC as a regulation, at least as
to this section) states in Annex F, section 2.4 (10)
"The advanced television system standard must support backward compatibility
of future improvements with all generations of advanced television system
receivers and inherently support production of low cost receivers (not
withstanding that cost reduction through reduced performance quality may
also be used to achieve inexpensive products)."

The A-VSB initial proposal, as pertains to PSIP, wasn't backwards
compatible, at least for fully-compliant PSIP implementations.

That's because all fully-compliant decoders would have excluded from PSIP
processing all packets that had adapration fields.  When I was first asked
about this by a Samsung consultant, I said it wasn't backwards-compatible.

I can say that t3/s8 has asked various equipment vendors (including even me)
about several ways to permit A-VSB without breaking compatibility.

None involves a simple word change.  There are various trade-offs in the
various approaches.  Since I've acquired some information outside of the
ATSC processes, I can say that the sticking point last time I discussed this
had to do with how many packets out of x will not have adaptation fields and
training signals, and thus can carry PSIP sections.  Another way of looking
at this is that the value would determine the maximum bit rate for PSIP.

One approach I was asked about would have significantly reduced the maximum
bit rate for PSIP from that specified in A/65.  As a practical matter, the
bit rate would have been sufficient for most of today's PSIP needs.

However, my feeling was that it would have made A-VSB unlikely to exist in
the same transport stream as data broadcasting since the data needs to be
referenced in PSIP.

>From an authoritative Samsung source, I know that the sticking point a few
months back was just how many packets out of x wouldn't have the adaptation
field/training signal.

I can live with the lowest value I've heard of, and there is a high value
beyond which Samsung has told me they will drop the idea.

Kind of funny to overlay this two-year process that purportedly involves a
simple wording change with the influence of Harris and LG upon ATSC and
their new proposal.  Makes one ponder which will first get to the candidate
standard status.  Could they arrive at the same time?

John Willkie



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