NMOS Glossary
←FAQ · Index↑ · NMOS Solutions→
In NMOS, several common terms have specific meanings that it helps to be aware of. Many of these correspond to the glossary of the JT-NM Reference Architecture.
Several of these are formally defined in NMOS specifications, for example in the IS-04 Data Model, but are described here for convenience.
API
An Application Programming Interface provided over a protocol such as HTTP or WebSocket, defined in an AMWA NMOS Specification (IS-04, IS-05, IS-06, etc.).
Client
The entity that is using an API, for example:
- a Node using the IS-04 Registration API
- a monitoring application using the IS-04 Query API
- a connection control application using the IS-05 Connection API
The Client is distinct from the User.
Controller
A Controller is Client software that interacts with the NMOS APIs to discover, connect and manage resources (Nodes, Devices, Senders and Receivers) within a networked media system.
Device
A Device is a logical block of functionality within a networked media infrastructure. Examples of Devices include:
- Camera
- SDI to IP adapter
- Chroma keyer
- Audio mixer
A Device can have a permanent presence on its Node (a fixed Device, e.g., a networked camera), or it can be created on demand by its Node (a virtual Device, e.g., a software-based transcoder). Nodes can dynamically create different types of Device (a dynamic Device).
Essence
Essence is video, audio or other data.
Flow
In the IS-04 and IS-05 specifications a Flow refers to a sequence of Essence Grains, that is video, audio or time-related data, generated by a Source. A Source can generate multiplexed Flows consisting of more than one kind of Essence.
This is a relatively high-level usage of the word, not to be confused with a low-level flow within the physical network (distinguished as a Network Flow in the IS-06 Data Model).
In addition to indicating the format of its Source, a Flow identifies the media type and parameters of the particular rendition.
Grain
NMOS uses Grain as a convenient way of identifying a unit of Essence, that is video, audio or time-related data. This helps with mapping NMOS’s logical data model onto physical Specifications.
For example, a video Grain could correspond to a frame of video.
Node
A Node is a logical host for Devices. This can be physical, or virtual (and a Node can be within a “cluster” or “cloud”).
In JT-NM TR-1001-1, the EBU Technology Pyramid, and other industry documents, the term Media Node is often used.
Receiver
A Receiver consumes a Flow transmitted on the network by a Sender.
A Receiver identifies the transport protocol it uses to communicate over the network and the data format it can accept.
Registry
A Registry, or Registration & Discovery Instance, is a Server that provides the IS-04 Registration API for Nodes and the IS-04 Query API for Controllers.
Sender
A Sender makes a Flow available on the network.
A Sender identifies the transport protocol it uses to communicate over the network.
For example, a Sender could transmit an RTP stream according to a payload mapping for a specific video format, or a sequence of data Grains via the MQTT or WebSocket protocols.
Server
The entity that is providing an API, for example:
- a Registry implementing IS-04 Registration and Query APIs
- a Node implementing IS-04 Node API and IS-05 Connection API
Source
A Source represents the logical origin of any number of Essence Flows, each of which is a rendition of the Source.
A Source therefore identifies the common format of its Flows.
For example, a Source could generate Essence based on its Device’s input signals, such as a camera image sensor, HDMI input signal, received RTP streams, or an internally generated test pattern or file read from storage, etc.
Note that a Source is:
- not a Device from which the content originates (for example there might be video, audio and perhaps data Sources associated with a camera, the camera itself is the Device not a Source).
- not about the physical origin of the Flows (for example: two Flows associated with the same Source might physically originate from different hardware in distinct geographical locations).
User
Where specifications refer to a User, this can include both human operators who drive a Controller manually and automation systems that drive a Controller programmatically.