[opendtv] Re: How to understand ATSC standards

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: