[opendtv] Re: Sixty-three TV stations to launch mobile DTV service this year
- From: "John Willkie" <johnwillkie@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Thu, 15 Jan 2009 10:24:40 -0800
John;
I can't say that I have examined every possible angle, but I am not familiar
with CS/153 populating any reserved data fields.
Let me start off with A/65c, the PSIP standard. The only references to
A/65c in M/H is to the content_advisory_descriptor and the Rating Region
Table (RRT). There is no other overlap between A/65c and CS/153, so there
is no use of reserved fields there. I can see a possibility in that area,
having to do with an OMA-BCAST service guide to supplant or extend the EPG
in PSIP and transmit service guide fragments in the main stream. (Logos!)
But, this would require some work.
For A/53:2007, I don't think there is any use of reserved fields, either.
Cs/153 contemplates a whole new set of training signals, but after much
processing, they are put into the main service and get the same processing
as does main service packets, including the training signals that apply to
the main service.
Indeed, I think that stuff -- to the extent I understand it -- is quite
elegant.
I don't know enough about how these new, enhanced training signals could be
used in the main service, but I guess it's possible, and might be an
interesting IP exercise for those who are in the right situations.
I know there has been some suggestion about the possibility of using M/H
data in home receivers. Indeed, that was the basis -- a long stretch -- for
my suggestion that nothing in the U.S. code would forbid substituting an M/H
service for the mandatory main service "SDTV service in the clear"
requirement.
I suspect that fixed receiver usage might be a reason why there is support
in CS/153 for scaleable video coding (SVC) in the document. But, this might
be a rather small niche, since SVC is optional, and that might be too small
a target for ce makers.
I'd be interested in you pointing me to reserved fields in A/53:2007 and
A/65c that you believe now will be unreserved as a result of CS/153 being
adopted.
At a functional level, A53:2007 and A/65c are the purview of ATSC's S8
subcommittee. CS/153 is owned by S4. I'm not familiar with any liaison
between the two subcommittees, nor any reason for such a liaison.
The "Reason" that E-VSB required FCC action to be legal in the U.S. is that
it made use of new pid value reservations, including the pid for PAT-E,
STT-E, PSIP-E base pid, etc.
ATSC M/H uses a totally different scheme for signaling (akin to MPEG-2 PSI)
and radically different ways of announcement (akin to PSIP). Both involve
MHEncoded IP datagrams, the latter is simply sending XML fragments, with
specified linkages to signaling elements.
John Willkie
-----Mensaje original-----
De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En
nombre de John Shutt
Enviado el: Thursday, January 15, 2009 6:51 AM
Para: opendtv@xxxxxxxxxxxxx
Asunto: [opendtv] Re: Sixty-three TV stations to launch mobile DTV service
this year
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.
----------------------------------------------------------------------
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: