NVIDIA/nvnmos

NVIDIA/nvnmos

Description: NVIDIA NMOS (Networked Media Open Specifications) Library

Language: Rust

License: Apache-2.0

Stars: 20

Forks: 5

Open issues: 1

Created: 2024-07-12T17:35:23Z

Pushed: 2026-06-09T20:25:16Z

Default branch: main

Fork: no

Archived: no

README:

NVIDIA Networked Media Open Specifications Library

Introduction

The Networked Media Open Specifications (NMOS) enable the registration, discovery and management of Media Nodes.

The NVIDIA NMOS control plane library, NvNmos, provides the APIs to create, destroy and internally manage an NMOS Node for a Media Node application. It is intended to be integrated with an ST 2110 data plane library such as NVIDIA Rivermax or NVIDIA DeepStream.

The library can automatically discover and register with an NMOS Registry on the network using the AMWA IS-04 Registration API.

The library provides callbacks for NMOS events such as AMWA IS-05 Connection API requests from an NMOS Controller. These callbacks can be used to update running DeepStream pipelines with new transport parameters, for example.

NvNmos currently supports Senders and Receivers for video, audio, and ancillary data flows over RTP (i.e., SMPTE ST 2110-20, -22, -30, and -40 streams) and over the Media eXchange Layer (MXL).

The NvNmos library supports the following specifications, using the Sony nmos-cpp implementation internally:

• AMWA IS-04 NMOS Discovery and Registration Specification v1.3
• AMWA IS-05 NMOS Device Connection Management Specification v1.1 and v1.2-dev (for MXL)
• AMWA IS-09 NMOS System Parameters Specification v1.0
• AMWA BCP-002-01 Natural Grouping of NMOS Resources v1.0
• AMWA BCP-002-02 NMOS Asset Distinguishing Information v1.0
• AMWA BCP-004-01 NMOS Receiver Capabilities v1.0
• AMWA BCP-006-01 NMOS With JPEG XS v1.0
• AMWA BCP-007-03 NMOS With MXL v1.0-dev
• Session Description Protocol conforming to SMPTE ST 2110-20, -22, -30, -40, and ST 2022-7
• MXL flow definition JSON as consumed by the MXL SDK

Supported Platforms

The library is intended to be portable to different environments. The following operating systems and compilers have been tested.

• Ubuntu 24.04 with GCC 13
• Windows 10 with Visual Studio 2022

Usage

NvNmos consists of a single shared library (_libnvnmos.so_ on Linux, _nvnmos.dll_ on Windows). The API is specified by the _nvnmos.h_ header file.

The nvnmos-example application demonstrates use of the library.

Transports

Each NvNmosSenderConfig and NvNmosReceiverConfig includes a transport field (an NvNmosTransport enum) that selects the transport. A zero-initialised configuration defaults to RTP. The transport_file field then holds the transport file as the appropriate text:

| transport | transport_file format | Reference | | --- | --- | --- | | NVNMOS_TRANSPORT_RTP | Session Description Protocol (SDP) per SMPTE ST 2110 / IETF RFCs | RFC 4566 | | NVNMOS_TRANSPORT_MXL | MXL flow definition (JSON) as consumed by the MXL SDK | MXL SDK |

NvNmos Extensions to the Transport File

NvNmos uses a small set of extensions in the transport file to convey configuration that the standard transport file format does not carry. The same conceptual extensions are carried differently in the two transport file formats:

• For RTP (SDP), as custom a=x-nvnmos-*: attributes.
• For MXL flow definitions (JSON), as entries in the standard tags property keyed by urn:x-nvnmos:tag:* URN strings. The tag's value is an array of strings; the first element is used.

| Concept | SDP attribute (RTP) | MXL flow_def tag key (MXL) | Applies to | Description | | --- | --- | --- | --- | --- | | Name | a=x-nvnmos-name: | urn:x-nvnmos:tag:name | Senders and Receivers (required) | The application's caller-chosen name for the Sender or Receiver, unique within the Node for the given side (Sender or Receiver). A Sender and a Receiver may share the same name. Used in all NvNmos API callbacks (paired with the NvNmosSide) | | Group hint | a=x-nvnmos-group-hint:| standard urn:x-nmos:tag:grouphint/v1.0| Senders and Receivers (optional) | A group hint tag advertised via urn:x-nmos:tag:grouphint/v1.0 on the NMOS resource | | Suppress narrow Receiver Caps | a=x-nvnmos-caps: (media-level) | urn:x-nvnmos:tag:caps | Receivers (optional) | An empty string value selects a fully-flexible Receiver, with format-derived Capabilities omitted. Non-empty strings are reserved for future capability; today any value is treated the same. | | Interface IP | a=x-nvnmos-iface-ip: | n/a | Senders and Receivers (RTP only) | The interface IP address used for IS-05 transport parameters (source_ip / interface_ip) | | Interface metadata | a=x-nvnmos-iface: [] [ ] | n/a | Senders and Receivers (RTP only) | IS-04 nmos::node_interface fields for interface_bindings and Node interfaces; used when present in the transport file, otherwise the library derives the binding from host interfaces ([design](doc/designs/x-nvnmos-iface.md)) | | Source port | a=x-nvnmos-src-port: | n/a | Senders (RTP only) | The source port from which the stream is transmitted | | MXL domain id | n/a | urn:x-nvnmos:tag:mxl-domain-id | Senders and Receivers (MXL only, required)| The MXL domain identity (UUID) for the Sender or Receiver; the IS-05 mxl_domain_id transport parameter defaults to "auto" and is resolved at activation time from this value |

For an MXL flow definition, the tag entries are stored alongside (and follow the same shape as) the standard urn:x-nmos:tag:grouphint/v1.0 tag, e.g.:

"tags": {
"urn:x-nmos:tag:grouphint/v1.0": [ "video-sender-1:Video" ],
"urn:x-nvnmos:tag:name": [ "video-sender-1" ],
"urn:x-nvnmos:tag:mxl-domain-id": [ "1ac254d9-c9be-475a-93a7-f80b9c1063a8" ]
}

NvNmos also publishes the urn:x-nvnmos:tag:name tag on the corresponding NMOS resources (visible to controllers via IS-04), so the URN is shared between the…