- NMOS Data Model Overview
- Accessing a Node's resources
- Timing
- Example System Architecture
- Registering and Discovering Nodes
- Connection Management
- Content Transport
This page is based on the original technical overview used by the AMWA Networked Media Incubator, before the NMOS family was created. It covers much of the current IS-04, including its legacy connection management mechanism (now deprecated), and the in-stream id and timing mapping for RTP.
Eventually all current information will be migrated elsewhere and this page will be removed.
NMOS uses a logical data model based on the JT-NM Reference Architecture to add identity, relationships and time-based information to content and broadcast equipment. Hierarchical relationships group related entities, with each entity having its own UUID (ID and UUID are used interchangeably in this document).
The traditional assumption of "different connectors for different signals" is replaced by the use of logical interfaces on common network interfaces, exposing video, audio and data inputs and outputs, and control parameters. This makes communication easier and helps with virtualization of broadcast equipment, with multiple devices operating on a shared physical host.
Data modeling -- identifying the important parts of a system and the relationships between them -- has an essential role to play in specifying what goes over the logical interfaces and will be an essential part of the transition of broadcasting and media production infrastructure to make the most of IP.
Nodes are logical hosts for processing and network operations. They may have a permanent physical presence, or may be created on demand, for example as a virtual machine in a cluster or cloud. Connections between Nodes through which content is transported are created to build a functioning broadcast plant.
Nodes provide Devices, which are logical groupings of functionality (such as processing capability, network inputs and outputs).
Devices with the capability to originate content must provide an abstract logical point of origin for this, called a Source. A Device may have multiple Sources.
Sources are the origin of one or more Flows, which are concrete representations of content.
Flows are composed of sequences of Grains. A Grain represents an element of Essence or other data associated with a specific time, such as a frame, a group of consecutive audio samples, or captions.
Grains also contain metadata information that specifies attributes such as the temporal duration of the payload, useful timestamps, originating Source ID and the Flow ID the grain is associated with.
As an example, consider the above concepts in the context of a video camera with an on-board microphone:
-
The camera itself is a Node, which provides a single Device with two Sources (one audio Source, one video Source).
-
The audio Source provides a single audio Flow.
-
The video Source provides (for the purposes of this example) two video Flows, one uncompressed, the other mezzanine encoded.
Sources, Flows and Grains are formalized in the NMOS Content Model.
Devices transmit and receive Flows over the network using Senders and Receivers. These can be respectively considered as "virtual output ports" and "virtual input ports" on the Device. Receivers connect to Senders in order to transport content.
Each Node represents the resources in its data model using a RESTful HTTP/JSON API called the Node API, which forms part of the Discovery and Registration Specification, and may also be used by future NMOS specifications.
The NMOS Content Model has been designed around the assumption that Nodes have access to a globally synchronized Clock to synchronize their Devices.
In typical usage (including the workshops of the AMWA Networked Media Incubator) the Clock is derived from GPS-locked PTP (using an epoch of 1970-01-01T00:00:00TAI) and is used to govern the capture of essence such as video frames, providing frame synchronization between discrete Devices.
Each Grain is timestamped using the Clock in order to provide the means for synchronization of Flows where required, and unique identity for Grains in time. Two timestamps are used for each Grain:
-
Origin Timestamps provide the original sampling instant of the media at the edge of the system, uniquely referenceable for all time.
-
Synchronization Timestamps provide a means to cross-reference between Flows which may have passed through the network fabric via different paths, or passed through processing chains (such as codecs) which impose different levels of delay.
By pairing these timestamps with Flow identifiers, it is possible to track a video frame or other essence through its chain of ancestors right back to the Device which originally captured it and the instant in time when that occurred.
This section describes the overarching structure of a broadcast plant using NMOS data model and APIs. It explores how Nodes communicate, and how a multi-Node system is created.
Regardless of their implementation, viewed logically, Nodes provide:
-
An HTTP API to allow clients to view and manipulate the Node data model.
-
Interfaces (in the logical sense) through which content is transported.
-
A PTP slave for timing and synchronization.
The Node HTTP API is specified within the discovery and registration specification.
NMOS does not specify the internal interfaces within a Node, although the following diagram may be helpful:
The Registration and Discovery Specification describes two mechanisms for discovery of Nodes and their resources: peer-to-peer and registered. Note that these two mechanisms may co-exist if this is operationally useful.
Peer-to-peer (P2P) discovery requires no additional infrastructure. Nodes make DNS Service Discovery (DNS-SD) announcements regarding the presence of their Node API. Peers browse for appropriate DNS records and then query the node HTTP API for further information.
Registered discovery takes place using a Registration & Discovery System (RDS), which is designed to be modular and distributed. An RDS is composed of one or more Registry & Discovery Instances (RDIs). Each RDI provides:
- A Registration Service
- A Query Service
- A Registry storage backend.
The Registration Service implements the Registration API (RESTful HTTP/JSON) of the NMOS Discovery and Registration Specification. Nodes POST to this API to register themselves and their resources. The Registration Service also manages garbage collection of Nodes and their resources by requiring Nodes to send regular keep-alive/heartbeat messages.
The Query Service implements the Query API (RESTful HTTP/JSON) of the NMOS Discovery and Registration Specification. Clients can GET lists of resources from this API. Typical usage examples include:
- Obtaining a list of registered Nodes in order to drive a configuration interface.
- Obtaining a list of Sender resources and a list of Receiver resources in order to provide a connection management interface.
The Query API also provides the ability to generate ‘long lived’ queries using its Subscription mechanism and WebSockets.
The Registration and Query APIs are specified within the discovery and registration specification.
The diagram below shows examples of peer-to-peer and registered discovery.
Note: this section describes a particular approach to making/removing connections between Senders and Receivers that the AMWA Networked Media Incubator has used for Connection Management for the first three workshops, and for the public demonstration of IS-04 at IBC 2016. The Incubator is developing a more general API for device connection management, which should form the basis of a future NMOS specification.
Sender and Receiver resources enable connectivity between Nodes. Senders expose a description of what Flow they are sending and an href to access it (the ‘manifest’).
For RTP, we use SDP files as our ‘manifest’. Senders expose an SDP file that describes the location of the Sender’s RTP stream. Note: other information in this SDP file is also used by the In-stream Identity and Timing Specification, which includes example SDP files.
To form a connection between two Nodes, a connection manager PUTs some structured data about a Sender (including a reference to the manifest href) to a Receiver. The Receiver parses the manifest and begins accessing the stream.
Each time a Receiver changes the Sender it is receiving from, the Node resource describing the Receiver must be updated on the Node, and also the Node must notify the Registration & Discovery system.
The diagram below shows a typical connection management sequence.
NMOS’s content model can be applied to several types of elemental payload format and transport protocol, including, but not limited to:
- Uncompressed video over RTP according to RFC 4175
- Uncompressed audio over RTP according to RFC 3190
- ST.291 ANC data over RTP according to draft-ietf-payload-rtp-ancillary-02
The above are used by VSF's TR-03 and are being standardized by SMPTE in the ST 2110 family of specifications.
In addition multiplexed streams are supported, in particular:
- SMPTE ST 2022-6 (SDI over RTP)
NMOS APIs include a "format" attribute to describe they type of Sources and Flows. Note: for successful operation with multiplexed streams, v1.1 or later of IS-04 is required.
NMOS In-stream Signaling of Identity and Timing information for RTP streams specifies how to apply the content model using RTP header extensions to carry identity and timing information and signal Grain boundaries. These can be extended to support e.g. mezzanine compression formats such as VC-2.
Future NMOS specifications may be produced to specify how to apply the content model to other types of content transport (e.g. HTTP-based).