Introducing Programming Metadata Communications Protocol  [PMCP Tutorial]

NOTE: EtherGuide Systems has developed and debugged the full PMCP (ATSC A/76) data interface for our broadcast metadata/PSIP generators.  During that process, a decision was made to leave this incomplete tutorial as is, without finishing or updating the content to reflect what we have learned of the PMCP interface.  Such information is shared with partners and customers.  In additon, EtherGuide Systems provides PMCP-specific information that is accessible on the customer-specific areas of this web site.  We apologize if this inconveniences competitors and those at Fortune-500 companies that seem to repeatedly visit this tutorial, but our focus is on customers. 

Consulting services are available from EtherGuide Systems if you or your company need assistance with a PMCP implementation or understanding how PMCP works in the broadcast metadata/systems environment, but you or your company is not desirous of an actual PMCP-powered PSIP generator.

The Programming Metadata Communications Protocol (PMCP) was developed and published by the ATSC's T3/S1 specialist group as ATSC specification A/76 to provide a standard XML schema for the exchange of data needed to generate and stream all the MPEG-2 private table sections needed to dynamically create ATSC-compliant Program Specific Information (PSI) and PSIP.

The intellectual author of PMCP is Frederick Grenier of Thales Electronics, which is now a unit of the Grass Valley Group, Inc.  At the ATSC, the standards development work was headed by Graham Jones, the Director of Communications Engineering, Science & Technology of the National Association of Broadcasters (NAB).

The candidate standard "CS75" was released by T3/S1 in January, 2004 and the initial version of the specification was finalized and published in November, 2004.  (Between release of the candidate standard and adoption of the specification, a previously-undiscovered numbering conflict caused "candidate standard 75" to be renumbered to specification A/76.  Subsequently, the A/76 schema was modified and extended to include transmission of ACAP data broadcasting metadata and signalling, and to correct minor errors in the initial document, with all but the corrections being backwards-compatible with the initial version of the specification..

The Regulatory case for accurate, dynamic PSIP

Hey

The Business and Technical Cases for PMCP

ATSC-compliant transport streams have unique characteristics and conditions that are foreign to transmission systems based on other MPEG-2 "users" like ARIB, DVB and, to a lesser extent, to those of SCTE. 

While the others generally permit a wide variety of transport stream bit rates, ATSC terrestrial and cable transmissions only permit  two basic rates, with one of those -- 16-VSB -- not having ever being used in practice, at least to the date of the writing of this tutorial..  In addition, there are many constraints that the ATSC A/52 Digital Audio and A/53 Digital Television standards impose on MPEG transport streams, constraints that have no direct counterparts in the DVB or ARIB 'worlds.' 

These constraints go well beyond the infamous 'Table 3' that is the only portion of the specification not incorporated by the United States Federal Communications Commission (FCC) in digital TV regulations.

These requirements are expected to be routinely and consistently observed, regardless of changes in the dynamic program offerings of the 8-VSB transmitting or relaying stations. 

Before PMCP, each of the devices in the transport stream employed proprietary interfaces that systems needed to master to control or understand device settings.  For a PSIP generator to understand transport stream settings, it would need manual entry of settings or have data interfaces with audio encoders, video encoders, multiplexers and perhaps even the exciter.  In most situations, each device would employ a unique proprietary interface data scheme.  In such arrangements, keeping track of changes in settings becomes a task of communicating in multiple languages to multiple devices, all at the last moment and at the same time.

 It quickly became clear -- to everyone save the defenders of proprietary data interfaces -- that a comprehensive protocol was needed to provide for the exchange of information between devices in the transport stream.  Not only would such an approach enable PSIP generators and other devices creating or reading broadcast metadata to acquire the information needed to create and transmit MPEG-2 Program Specific Information (PSI) and ATSC Program and System Information Protocol (PSIP), but any other device that processes broadcast metadata in the transport stream would have a mechanism for communicating the information contained within broadcast metadata.

Other than using the various proprietary interfaces, the only other way to communicate transport stream metadata before PMCP was to transmit a minute or two of the transport stream itself.  One minute of an 8-VSB transport stream amounts to something close to 142 megabytes of data.  A PMCP file that contains all the metadata in the transport stream as well as the data needed to create the metadata would amount to perhaps 50 kilobytes of data.

Although the vast majority of all ATSC transport streams are devoted exclusively to terrestrial broadcasting, such an arrangement or scheme should empower ATSC transmissions in terrestrial, cable and satellite networks, and should be extensible so that future enhancements to ATSC transport streams can be effectuated via devices that exchange PMCP data. 

Such a scheme, or data schema, should be able to be used for file as well as live "sockets" data transfers and should work, or be able to work, with any and all current and future devices that might contribute data to the transport stream.

Such is the promise, and to a large extent, the delivery, of the ATSC's Programming Metadata Communications Protoco (PMCP), which is published as ATSC Specification A/76.   

PMCP is widely supported by makers of traffic, program management, automation and PSIP generators. It is safe to say that if a vendor of one of these systems doesn't fully embrace PMCP, they want to bind customers to their own proprietary interfaces, which will just increase the cost of implementation and operation above that of comparable PMCP-centric systems.

EtherGuide Systems has and will continue to fully embrace PMCP in all of our ATSC-centric products and systems, and is we are committed to developing public or private PMCP extensions to support all current and future technologies used in ATSC transport streams.

PMCP in a nutshell

PMCP is a publicly-published data schema and specification contained in two documents, ATSC A/76 and A/76a, that describes an XML schema for the communication of information about ATSC-compliant transport streams and program elements within the transport stream.  While PMCP can be extended to describe DVB- and ARIB-compliant transport streams, such work is beyond the scope of this tutorial.  XML stands for eXtensible Markup Language and is a sister specification to HTML, which is the language behind all web pages.

PMCP data can enter or leave a device as a file or via UDP/IP or TCP/IP transmissions, or, conceptually using other forms of transmission that are not described in the PMCP specification. 

PMCP is constructed as one ore more messages that emanate from one device and which may be received by one or more devices.  Each message must comply with the requirements of the PMCP schema.  One or more messages make up the data set that is used to create PSIP.  The schema provides for messages that add, udate, delete or merely read data stored in the receiving device.

The PMCP schema includes some mandatory elements that need to be included in any message that uses a particular PMCP object, generally because that is the only method usable to access the object.  Nothing in the schema requires that any single message have all the elements needed to construct a particular object; this is left up to implementers..  So, while the PMCP schema employs rigid rules on the format and content of messages, there is still enough room in the schema to easily make human errors in defining program elements.

For Internet use, the port number 3821 has been reserved for PMCP use, although PMCP users are free to use any commonly-understood port number for Internet communications.