AV/IT Interoperability Utopia?

We sat down with Paulo Francisco, vice president of engineering at Evertz AV to answer a few pressing questions about IPMX. 

What is driving the need for IPMX and what does IPMX hope to achieve?

In industries where interoperability between products from different vendors is crucial, we often see a specific technological evolution. When the industry needs a novel solution to tackle a new problem or solve an old problem differently, a small set of industrious R&D companies will take up the challenge. In time, other product manufacturers see an opportunity and do the same. Over time the existence and viability of a new market segment is proven, and end users are empowered with a multitude of solutions to choose from. Although this may be advantageous, in terms of a large product selection, it also causes confusion for end users left parsing through marketing claims as to which technology is better for their application. Eventually, there comes a need for a form of technology consolidation or a common way to ideally solve the original problem and enable multiple product manufacturers to interoperate. That is, in essence, the purpose of an open standard like IPMX. It defines one way, with open standards and specifications, to implement AV-over-IP enabling multi-vendor interoperability and empowering end users with the ability to pick best-in-class vendors with the assurance that all products will co-exist and interoperate.

Will IPMX products assure interoperability?

Well, not so fast. Like all standards, the IPMX standard is a collection of documents in a prioritized order starting with the essential components and adding, over time, less common capabilities. The published and draft TR10-XY documents can be viewed here. When several companies and engineering teams review a set of standards, it is inevitable to have different interpretations of the written text. To that end, an essential component of any standard is to define a set of testing criteria that a product must pass to be certified and claim “compliance”. This testing can come in different forms ranging from less formal “plug fests” or hosted testing events, such as what was done for 2110 via JTNM testing, to more formal and controlled independent testing by accredited labs.

At present, the testing and certification requirements for IPMX is a work in progress. All manufacturers are working together in good faith to maximize this interoperability, but it cannot be guaranteed, nor can a manufacturer claim to have a guaranteed compliant solution.

Will IPMX interoperate with SMPTE-2110?

Throughout the definition of the IPMX open standard, every effort was made to leverage SMPTE ST 2110 and AMWA NMOS, where possible, and create extensions or relax requirements where needed. As such, there is a great deal of interoperable overlap between IPMX and SMPTE-2110, but they are obviously two separate standards with IPMX driven by the need to address the unique and wide requirements of the pro AV market and expected ease of use.

The simplest way to think of this is to start with stream compatibility. A 2110 sender, supporting only uncompressed 2110-20 video, clearly can’t send a stream to an IPMX receiver running at 1G and expecting 2110-22 compressed video. May seem silly to even describe this example but such scenarios can quickly get lost in the excitement of IPMX being stated as interoperable with 2110.

Even in a best-case scenario, such as two 2110-20 uncompressed systems, one needs to consider that pro-AV sources may be content protected and require HDCP support to be processed and sent over IP to a destination which must also support HDCP. This precludes successfully sending such a protected source to a broadcast 2110 SDI destination.

For the cases where IPMX and 2110 domains “meet,” such as a standard 1080p or 4k60 uncompressed video stream, with the usual well defined 48k audio stream, then one is almost assured interoperability provided that there is agreement on timing. IPMX does not mandate the use of PTP synchronization while SMPTE-2110 expects synchronous sources locked to PTP timing. This essentially means that a 2110 source can almost always be received by an IPMX receiver while an IPMX sender would need to ideally support PTP and run in synchronous mode to maximize interoperability. This is noteworthy because IPMX targets many applications and scope of devices, and one option is for a sender to run asynchronously and use RTCP sender reports to dynamically define the sent stream.

So IPMX and SMPTE-2110 interoperability requires a thoughtful system architecture, that takes into consideration all needed workflows, and multi-vendor IPMX interoperability requires patience and time for certification guidelines to be published, vendors to get certified and, almost for certain, a few IPMX software updates along the way.

Some say that PTP is not mandatory while others say that it is. Which is it?

So, in the end, everyone was correct. PTP is not mandatory for an IPMX pro-AV deployment thus allowing for simple low-cost topologies with consumer asynchronous free-running sources. For high-end broadcast systems, where PTP is always present, IPMX is mandated to use it.

The IPMX standard defines what essentially amounts to three possible modes of operation with the goal of providing maximum flexibility for both product and deployment complexity.

The first thing to consider is the media source itself. Classic broadcast SDI sources have a genlock capability and generate a media stream that is locked and synchronized to a housemaster clock. In the world of IP, this master clock signal is PTP. Classic pro AV sources, on the other hand, are often HDMI or Display Port and have no synchronization capability. These are asynchronous sources running under their own locally generated timing which is conveyed as part of the physical interface signaling.

IPMX cleverly allows for:

a: Synchronous sources locked to PTP
b: Asynchronous sources with PTP offset information conveyed over IP
c: Asynchronous sources with sender gateway timing offset information conveyed over IP

Scenario (a) follows a standard SMPTE ST 2110 approach. Scenario (b) uses an IPMX-specific technique called “RTCP Sender Reports” to convey timing offset, between the asynchronous source and PTP, to facilitate re-alignment at the receiving gateway. Scenario (c) is the same as (b) except that every gateway uses its own locally generated clock and although this still facilitates source switching recovery, it does not allow for frame re-alignment as there is no synchronization between the various sender gateways themselves.

So, in all cases, timing information is conveyed to a gateway receiver but the benefit varies. Scenario (a) delivers broadcast quality seamless switching and is compatible with 2110 receivers. Scenarios (b) and (c) rely on the receiver understanding RTCP Sender Reports, which is unique to IPMX, and although scenario (b) allows for frame re-alignment, scenario (c) does not.

The IPMX standard mandates that IPMX sender gateways leverage and synch to PTP if it is available. This means that only scenarios (a) and (b) are relevant in a hybrid IPMX / 2110 deployment. More sophisticated 2110 receivers will still be able to derive timing and show video for scenario (b) but interoperability and optimized performance is not guaranteed.