The ATSC implementation of MPEG-2 technology provides broadcasters with tremendous potential and ample bandwidth to deploy traditional and innovative broadcasting services. To make the most of the potential, traffic, automation, ingest, content management and transmission subsystems must interoperate harmoniously in real time.
Previously, many broadcast systems vendors propounded proprietary data interfaces and all-encompassing solutions. The first decade of digital broadcasting was limited by the cost and difficulty of implementing and testing proprietary interfaces for each device needed to seamlessly transmit video, audio and data services. By one count, more than 200 interfaces needed to be supported.
As an example, a traffic system could be expected to communicate with a PSIP generator using one interface and protocol, exchange schedules and as-aired log information using one or more other interfaces, and communicate with automation or content management systems via yet another interface. When new systems were adopted in the facility, each of the existing devices would need to be reconfigured, updated or replaced to support each new device. Expecting devices from a variety of vendors to work faultlessly in real time with such arrangements is unrealistic and expensive for both stations and vendors.
Compatibility and interoperability are key
Fortunately, the visionary ideas of two engineers — and the ATSC and SMPTE subcommittees that developed their ideas into complete specifications — has enabled broadcasters a clear path to dynamic digital services. This means making sure that all future broadcast systems support either the Programming Metadata Communications Protocol (PMCP) or the Broadcast Exchange Format (BXF), or both.
These two compatible and interoperable protocols have widespread support among broadcast vendors. The adoption of nonproprietary interfaces for these mission-critical systems foretells a future where vendors concentrate on features and particular advantages instead of developing and debugging interfaces that they defend unto death. For broadcasters, the protocols mean that decisions on future system purchases will be based more on price, value and features instead of which system supports the interfaces of existing systems.
The story behind PMCP
PMCP, specified in ATSC A/76, established an eXtensible Markup Language (XML) schema for exchanging data elements used by Program and System Information Protocol (PSIP) generators to describe virtual channels and the programming events on each virtual channel. (For more information about PMCP, see “Web links” on page 72.)
Fred Grenier of Thomson Grass Valley helped develop the Pearl PSIP generator, which could be integrated with the company's Amber multiplexer. With multiplexers and encoders available from many vendors, this tie-in minimized the potential of Pearl. Grenier devised an XML data interface that extended the utility of the PSIP generator. All that was required was for the other systems that communicate with PSIP generators to support the interface.
As a practical matter, the interface had to be developed and adopted by a standards development organization, enabling interested vendors and users to ensure the protocol answered their needs and desires. XML interfaces were new to the broadcasting systems field, so finding the right group to develop the specification involved convincing others of the value of nonproprietary interfaces.
In due course, the ATSC board of directors decided that the work should be the basis of an ATSC voluntary specification for the transmission of metadata within a broadcast facility. The ATSC S1 specialist group was chartered with the task of fashioning the specification, under the direction of the NAB's Graham Jones, S1 chair at the time. The ATSC published the first version of the PMCP specification in late 2004.
How PMCP works
PMCP exchanges data used to create PSIP in the form of XML text messages. A message can be sent as a file download or transmitted to other devices using Transmission Control Protocol (TCP) and Internetworking Protocol (IP) or User Datagram Protocol (UDP) and Internetworking Protocol (IP) communications protocols. Even when using the connectionless UDP/IP, message delivery can be assured. Periodic “heartbeat” messages signal a device is truly alive. (See Figure 1 on page 70.)
Within the XML message wrapper, a PMCP message can add, update, read or delete one or more items of data stored in a PMCP-compliant device. Top-level elements describe the analog and digital signals of a station; each of the virtual channels; and “Events” (what viewers would call programs), V-chip ratings and time parameters. An abstract element labeled “Show” permits defining a TV program regardless of when it is scheduled to air.
Upon receiving a PMCP message, a device validates the message against the schema. If all the elements are well formed and comply with the schema, the message is processed into the data forms needed by that device. While PMCP messages might be in textual form, the data is dense and verbose. XML data is about as easy for humans to use as is the HTML source code of a Web page.
Although adoption by some vendors lagged for a while, now all vendors of dynamic PSIP generators in North America support PMCP as a standard or optional feature. Program listings from TitanTV.com are available in PMCP form, but currently, Tribune Media Services hasn't announced support for the protocol. Many automation and traffic systems vendors support PMCP, as do program management vendors.
The Internet Assigned Numbers Authority (IANA) assigned port 3821 for PMCP communications, so aside from security concerns, a PSIP generator doesn't need to be in the same area code as the device that controls it.
The birth of BXF
In 2006, under then-S1 chairman Art Allison (of the NAB), the PMCP specification was extended to include all metadata elements needed to announce Advanced Common Application Platform (ACAP) data broadcasting services (specified in ATSC A/101), and to make minor editorial corrections in the schema.
One of the founding members of the ATSC group for PSIP Metadata Communication during the development of PMCP was Chris Lennon of Encoda Systems (now a part of Harris Broadcast). For years, Encoda had been trying to leverage its proprietary traffic system interfaces into a strong position in automation and similar systems.
Lennon had a different idea. He wanted to create an XML schema that would overcome the forest of proprietary traffic system interfaces among traffic, automation, playout, switching and program management systems. He had wanted the ATSC to form a group to develop his idea into a published specification, but before work on PMCP started, he was told to take his idea to SMPTE.
By the time of publication of the PMCP standard, SMPTE formed an ad hoc group chaired by Lennon to develop his idea into a full specification. Eventually, that group became a full SMPTE working group called S22-WG10 on Data Exchange in the Technology Committee on Television Systems Technology. The resulting standard, SMPTE 2021, or BXF, should become a final SMPTE specification this year. Some system vendors have already installed BXF-based systems. (For more information about BXF, see “Web links.”)
Comparing BXF with PMCP
For a specification like PMCP or BXF to benefit users and vendors, it must address a variety of needs and be adopted by a wide spectrum of vendors. Even before publication, it is safe to say that will be the case with BXF. Virtually all traffic, automation, ingest, and content and program management system vendors are members of S22-WG10 and have fully participated in the development of SMPTE 2021.
The remit of PMCP is much simpler than that of BXF. For example, a PMCP message might tell a PSIP generator to change the title and description of the TV program that begins on channel 51 at 9:30 p.m. tomorrow. A PSIP generator, once given the information and instruction, can transmit the appropriate bits at the correct time without any further interaction.
By comparison, the BXF protocol has to enable synchronizing and coordinating transitions and switches between programs and commercials, along with graphics overlays, effects and voice-overs to transmit seamless multimedia presentations. BXF uses a message structure similar to that used with PMCP. The two protocols are complementary and interoperable, with no overlap in functionality.
There are four types of BXF messages: request, information, heartbeat and message status request. Where PMCP supports timing accurate to the second (with optional frame-accurate timing), BXF timing is specified to the millisecond. (See Figure 2.)
Both PMCP and BXF provide for the exchange of private data elements, permitting implementers and users to extend data exchanges without breaking either protocol. Using XML tools such as XML Spy or XML Writer, even humans can create valid PMCP or BXF messages, albeit slowly. (See “Web links” for more information about XML Spy and XML Writer.)
Conclusion
Judging by the number of broadcast-oriented XML schemas that are currently in development or use, this IT-centric system of handling data between disparate devices has clearly reached the tipping point. You don't need to think back very far to remember a time when most digital broadcasting systems employed proprietary interfaces.
So, the next time you see Fred Grenier or Chris Lennon, thank them for making true digital broadcasting not only simple, but, in truth, possible.
John Willkie is the founder of EtherGuide Systems and is a member of the ATSC S1 and SMPTE S22-WG10 subcommittees.
Web links
- SMPTE 2021 BXF standard; www.smpte.org
- ATSC A/76 defining PMCP; www.atsc.org/standards/a76.html
- XML Spy; www.altova.com
- XML Writer; www.xmlwriter.com
