These Networked Media Open Specifications—better known as NMOS are a set of APIs that provide the means to discover nodes on a network and their associated resources related to the processing of video, audio and other data. These APIs are generated by the network node devices and are used to create a connection between sender and receiver data on the devices on which it is running.

“The NMOS IS-04 specification is the API that discovers and registers devices as they are connected to the network and is installed on each device they communicate with,” said Gary Olson, president of consultant firm GHO Group (New York) and an IP networking expert. Olson is also a frequent contributor to The Broadcast Bridge.

“On the endpoint side, each manufacturer needs to embed the appropriate API’s in their devices, build an interface accessible by a user and integrate NMOS with their product,” he said. “The integration includes sending and receiving NMOS along with the ST2110 essence package. The NMOS server is the controller that manages the transport and communication between devices, a broadcast (NMOS) controller, across the entire media network. This is essentially another layer in the full network and functions like an SDN.”

Unfortunately, due to a lack of industry wide understanding of how to deploy these NMOS specs, and the fact that they have not been officially standardized—leading to a variety of methods and incompatible implementation—adoption of these Networked Media Open Specifications (better known as NMOS) has been slow or a non-factor in many ST2110 media networks now being deployed.

“Adoption of NMOS has been slow initially, but appears to be growing,” said Brad Gilmer, Executive Director of The AMWA, the group responsible for developing the NMOS specs. “There is great pressure on vendors to adopt open specifications and standards to help their customers design and build the best workflows for their business. The EBU and WBU have both published statements of support based on their user members’ requests. Ultimately, no matter how broad a supplier’s product range is, proprietary standards don’t do anyone any favors. Understandably, end users don’t want to shop in just one place.”

According to Olson and many others, the fact that there is no consensus on how to implement these special APIs—by AMWA or any official body (although the EBU supports them publically)—is the real reason networked system designers have hesitated to deploy NMOS. At the end of the day they are simply a suggestion, not a mandate.

According to the AMWA website, “The NMOS family of specifications began with projects for Discovery & Registration, Device Connection Management and Network Control. It has grown to include important subjects such as Event & Tally, Audio Channel Mapping and Interoperable Security. Additional working groups become active as new operational / business needs are identified.

They are a growing family of specifications that are available to both suppliers and end users, at no cost, to support the development of products and services that work within an open industry framework. Wherever possible, the specifications are being developed using Internet standards or Internet-friendly techniques.”

So, why wasn’t NMOS standardized along with SMPTE’s IP standards? Gilmer said it’s important to remember that the approach for NMOS developments follows the IT industry, where adaptability and speed are key drivers to satisfy today’s fast-moving world. It comes down to two primary reasons. The AMWA board felt that the NMOS APIs needed to be developed quickly to support ST2110, and that they needed to be able to be updated much more quickly than would typically be the case with a standard.”

“SMPTE has tremendous expertise in essence formats,” he said. “ST2110 describes interoperable essence formats for video, audio and data. Having standards poured in concrete through a SMPTE Standard at the essence level for IP is absolutely critical as broadcasters move to the IP domain.

“The AMWA Networked Media Open Specifications operate at a higher level in the stack and are software APIs,” Gilmer continued. “The AMWA has been doing work on software-oriented architectures for many years, and we have a large group of software experts who specifically work with professional media. So the subject matter experts were there.”

Without standardization (and not part of the ST2110 standard), there has been a concern among many, that different equipment vendors can and do interpret the spec in their own way (e.g., the MXF). Also, they are not obligated to incorporate it, but realistically, it makes good business sense to stay compatible with third-party devices.

Support From Suppliers

“NMOS specifications tend to be compact APIs with carefully controlled scope, when compared with a typical standard,” Gilmer said. “This is actually a key concept for NMOS – atomic units of functionality. Of course, even with a relatively simple API, differences in interpretation can occur. For that reason, the AMWA has had excellent support from dozens of suppliers who, from the outset, have thrown their weight behind our interoperability workshops. These provided a very efficient opportunity for the (often competing) suppliers to collaborate to ensure that the interconnectivity was done in the same way.”

“In addition, the AMWA continues to develop an openly available testing utility which anyone can download for free from GitHub,” he said. “All of this is to make it easier to implement NMOS and to avoid different interpretations of the specifications.”

Gilmer said the AMWA has added virtual workshops to its original face-to-face meetings. In addition, the “JT-NM Tested” initiative, carried out by the EBU before the NAB and IBC trade shows, has added confidence that the vendors are accurate and consistent in their use of the NMOS developments. Online tests can also be carried out using toolkits built by members of the AMWA team.

For broadcast engineers tasked with deploying devices on a ST 2110 network, the confusion starts with who is responsible to use the API spec and write the code to put on the host server on the network when implementing NMOS as part of ST2110 installation.

“Well, it depends entirely upon what part of NMOS you are talking about,” Gilmer said. “But let’s assume that a system architect has decided they want to have a common NMOS IS-04 register on the network so that any devices, when they connect to the network, can register what they are and what they can do with a central repository. Typically I would think a vendor would provide this NMOS IS-04 registry and that it would run on a server on the network.”

Interoperable Ecosystem

He added that individual vendors must embed (or implement) various NMOS APIs in their products to build an interoperable ecosystem. Vendors write software in their applications that either present an interface that is listening on the network for incoming API commands, or they write applications that emit API commands, as in the case of a Broadcast Controller asking a camera (which understands the NMOS IS-05 API commands) to do what the Broadcast Controller asks it to do.

“Let’s assume that a system architect has decided they want to have a common NMOS IS-04 register on the network so that any devices, when they connect to the network, can register what they are and what they can do with a central repository,” he said. “Typically I would think a vendor would provide this NMOS IS-04 registry and that it would run on a server on the network. The user (or systems integrator) doesn’t need a programmer to do this as the vendor will typically provide the necessary programming code.”

What about the NMOS API: does it run as a service or an application on a server?

“The NMOS API is just a list of commands you can use to get things done,” Gilmer said. “Those commands don’t run anywhere. But those commands can be used like words in the English language. So in the case of IS-04, there is a registry application running on a server that understands the ‘language’ as defined in the NMOS IS-04 API Specification. If there is a camera that is also on the network, then that camera also knows the language as defined in the NMOS IS-04 API specification, so it can talk with a registry and tell that registry to make a new entry that contains information about the camera.”

Easy To Implement APIs

He added that, at the end of the day, the benefit of NMOS is that there are a collection of lightweight, modern, easy-to-implement APIs that support critical functions needed in order to enable an ecosystem around the SMPTE ST2110 standard for moving audio and video over an IP network.

“We are seeking to enable a common set of APIs that create a pool of compatible equipment and applications that can innovate on top of these critical common functions in order to create a market place as we transition to an IP world,” Gilmer said. “We are looking, potentially, at how NMOS might be used in facilities along with other popular control protocols such as ember+.”

The message regarding NMOS for broadcast engineers and the new generation of IT professionals now being hired to deploy ST2110 IP networks is to understand that while you could have 15 different ways to ask different devices to join the output of a particular camera, maybe it would be easier and involve less specialized translation—as long as everyone can agree on how a Broadcast Controller would tell a monitor or a switcher to do that.

“If you decide that, inside your plant, it is a good idea that there is a central registry where all devices go to post information about what they are and what they can do, then you can imagine that it could be helpful if everyone was speaking the same language,” Gilmer said. “You could, of course, hire a bunch of translators to translate incoming requests in different languages into English, but maybe it would be better if, when you wanted to register your device, everyone spoke the same language to the registry.”

The AMWA board is now working to further develop the JT-NM Roadmap (http://jt-nm.org/roadmap/), which was last updated in 2018.

Until a consensus is reached, broadcast engineers and network systems designers would be wise to plan carefully and, perhaps, hire their own coder to write custom APIs.