[opendtv] Re: How to understand ATSC standards
- From: "Adam Goldberg" <adam_g@xxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Fri, 23 May 2008 19:33:07 -0400
The rc_descriptor language is what it is because ATSC standards do not make
enforceable legal requirements on receivers (and, when it was defined, we
didn't know what the required behavior was to be). You shouldn't read too much
into the 'out of the scope of this standard' language, as it simply means
"there'll be a regulation which will be triggered when this construct is
present".
It's interesting that you bring up the DCCRR. I agree it is tortured and
convoluted. But it is precisely because of the above -- as originally drafted,
the DCC stuff would have defined specific receiver behavior. ATSC standards do
not have scope to do this. The DCC text was rewritten at least partially
because of my personal argument with the receiver requirement language (though
it could be better, but I wasn't going to write it ... and judging from the
marketplace adoption of DCC, it seems that I was right).
As for CEA-608 vs. A/65 on caption_service_descriptor, it was simply a matter
of timing. 608 got updated before A/65. If you check the current versions
(CEA-608-E, A/65C with amendment 1), it's mandatory in both places. Often the
discrepancies about optional things made normative is merely an artifact of the
standards development /timing/.
As to the AC-3 audio descriptor, ("M"), you've got it wrong. The definition of
"M" is not "optional", it's "when present, shall be present in each indicated
location". If AC-3 audio is in the program, both locations indicated by an "M"
are required to have an AC-3 descriptor.
The smoothing buffer descriptor is optional because the standard allows
emission of streams which are not smoothed. Therefore, necessarily, a receiver
which is able to decode all compliant streams is able to decode completely
un-smoothed streams. If an encoder decides to smooth it's output, that's fine,
and feel free to tell receivers about it (via the descriptor), but it's not
necessary.
The rearranging of stuff from 708 into (and from) various SMPTE and ATSC
standards has no effect on normative requirements, it's merely a shuffling of
things around (in order to make the standards layering more sensible).
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] On
Behalf Of John Willkie
Sent: Friday, May 23, 2008 6:25 PM
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] How to understand ATSC standards
ATSC standards for digital television build upon and make normative references
to MPEG-2 1 (systems) and MPEG-2 2 (video). Those standards are extensive and
include mandatory and optional elements.
The ATSC standards have a more limited scope. Basically, they extend (in some
cases) and constrain (in other cases) MPEG-2 specifications. At heart, they
define the interface between a transmission system and a reception system.
In a very few limited cases -- generally when there is a statutory or
regulatory need to be addressed, the standards tell a receiver what to do with
data elements. A good case in point is the content_advisory_descriptor, where
there is language in the A/65 standard that mandates just what a receiver is to
do (blank audio and video) when the user has set the unit to deny certain rated
content.
These are few and far between. Note in A/65 how the Directed Channel Change
section defines a DCCRR (reference receiver) and what it is expected to do.
The language is tortured, and that might have just a bit to do with the lack of
DCC in the real world.
When a standard says that something is "beyond the scope" of the standard, in
my experience, that means that one or more of the parties has requested this
language to clarify a possible ambiguity. Usually, with a bit of spelunking,
one can discern the ambiguity in language that comes before the statement.
That doesn't mean that the language can be removed later; it means that IT'S
OUTSIDE THE SCOPE OF THE DOCUMENT and absent some external change, removal of
the language is unlikely to EVER happen. More likely, another document would
have to be started to address the 'issue' before the language is removed.
However, one can sometimes find another document that does address the scope.
Also, one needs to keep in mind that, for the convenience of keeping documents
up to date, one document may make an item optional, but another document that
is a normative reference makes it mandatory. A good example is the
caption_service_descriptor, which in A/65 is listed as optional, but in CEA-708
(ATSC A/65 includes a normative reference to it) is made mandatory. In
situations like this, to do otherwise would mean that every time CEA-708 was
modified, A/65 would need to be modified.
From an implementers view, it simply means that you need to read ALL normative
references before you can understand the document you are reading. It means
that people who understand all the 'reference paths' have much greater
understanding of documents than does the person who only refers to one document.
Another good example: ATSC A/65 lists as optional (M) in table 6.25a the AC-3
descriptor for the Event Information Table and Program Map Table. However, if
one looks at A/52 or A/53 (normative references from A/65), one can clearly see
that the AC-3 descriptor is mandatory if there is an AC-3 service present.
MPEG-2 specifies an optional smoothing_buffer_descriptor. ATSC A/53 makes that
optional, and constrains it to apply to the whole program service (located, in
other words, in the PMT header), labels it the program smoothing buffer
descriptor, and even tells the receiver how to interpret the information in the
descriptor if it is also found in the part of the PMT that applies to
individual elementary streams.
A 'basic' understanding of ATSC specifications means that you have read and
understand, language in thousands of pages of ATSC, MPEG-2, DVB and SCTE
standards, understand the reference paths, and where optional language is
countermanded by mandatory language.
Reading one or two paragraphs in a single document won't do it.
And, I've simplified this analysis greatly. Last time I checked, the ATSC
standards in force at this moment under the FCC's rule sections refer to two
different editions of the CEA-708 specification (CEA-708B (June 1997) and
CEA-708C (July 30, 2006).
What to do in where language in the latter is contrary to language in the
former is "fun." Not only that, I do belive that there is a later version of
CEA-708 in the work, and some of the language in CEA-708C is being moved to
optional SMPTE standards, recommendations and engineering guidelines.
In other words, be very careful when an armchair quarterbck gives opinions
based on a limited understanding of one document in a thickset.
From my perspective, the highest quality information comes from people who have
read and understand the documents, and who have implemented the standards in
code which has been proven to interoperate with all devices made by other
makers. The next level is people who actively participated in the development
of the standards.
Ignore dilletantes.
I'll leave for others to decide where Bert and I fit into the above paradigms.
Perhaps he HAS written code.
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.
----------------------------------------------------------------------
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:
