[opendtv] Re: How to understand ATSC standards

I stand corrected on the "M".  I take it to be "may" when it is actually "must, 
if present."  I make this mistake way too often.

John

-----Original Message-----
>From: Adam Goldberg <adam_g@xxxxxxxxx>
>Sent: May 23, 2008 4:33 PM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [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.
>

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