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.