[opendtv] Re: Sixty-three TV stations to launch mobile DTV service this year
- From: "John Shutt" <shuttj@xxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 15 Jan 2009 09:50:51 -0500
John,
Well, I guess it would have been better if I also silently assumed that FCC
approval would be necessary for M/H to be implemented.
My eyes glazed over reading the candidate standard, not having the
background of you or Bert, but it seems to me that most of the 'secret
sauce' is creating more training symbols by manipulating the R-S encoder,
ala A-VSB, and using more FEC for the robust stream. (Plus the addition of
TDM for low power receivers.) I'm sure that's overly simplistic but that's
the best my layman's mind can do.
Question: What implications are there for an "M/H aware" main service
receiver (such as one built into a television or STB) to also use these
additional training signals for enhanced echo cancellation of the main
service? It would seem reasonable to me for a broadcaster to eventually use
M/H simply to convey the additional training symbols for next-generation
receivers to use, even if there is no actual M/H service transmitted.
As for not requiring FCC action, I did note that Candidate Standard A/153
does a lot of populating of data fields labeled as "reserved" in A/53:2007.
Data Field Sync is but one example. Also, Candidate Standard A/153 alludes
to new uses for reserved A/65C fields. Would that practice not run afoul of
A/53:2007 and A/65C, as adopted by the FCC?
A/53:2007 defines reserved data bits as:
"reserved: This term, when used in clauses defining the coded bit stream,
indicates that the value may be used in the future for Digital Television
Standard extensions. Unless otherwise specified within this Standard, all
reserved bits shall be set to "1"."
A/65C defines reserved fields as:
"reserved - Fields in this PSIP Standard marked "reserved" shall not be
assigned by the user, but shall be available for future use. Decoders are
expected to disregard reserved fields for which no definition exists that is
known to that unit. Each bit in the fields marked "reserved" shall be set to
one until such time as it is defined and supported."
In the eyes of the FCC, A/153 related PSIP fields would not be "defined and
supported" until they adopt A/153, no?
And E8-VSB, which is part of A/53:2007, also uses the null packet identifier
PID to "hide" enhanced mode data from legacy receivers. Specifically:
"For the purpose for maintaining strict backward compatibility for existing
receivers, 188-byte packets that contain Enhanced encoded data are composed
of a 0x47 Sync byte, followed by 3 bytes as defined by [1] that contain the
null packet designation (PID = 0x1FFF), and the 184-byte enhanced
segment[.]"
Populating null packets with payloads other than those defined under
A/53:2007's E8-VSB use may be in issue? I don't know.
Small nits, to be sure, and there may be intellectual property concerns as
well, unless the E8-VSB and A-VSB patent holders are on board with M/H.
Thanks for the education, John.
----- Original Message -----
From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
I read the assertion in the summer in a forum that forbids participants
from
disclosing communications or deliberations. I (silently) assumed the
person
was wrong, so I reviewed all the documents I had access to, in the state
they were in. I had to conclude that they were correct, and a few nits
have
been removed since then.
----------------------------------------------------------------------
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:
