Networked Media Open Specifications

Data Model: Identifier Mapping

←Data Model · Index↑ · Upgrade Path→

Identity is a core part of a flexible architecture for networked media. Associating IDs and timestamps with essence at the point of capture provides us with the capability to track a video frame or other content’s ancestry through the production chain and back to the device which originally captured it. Definitions for each of the logical entities described here is available via the JT-NM Reference Architecture (http://www.jt-nm.org).

In order to ensure consistent behaviour in a production facility employing this identity, some rules must be applied when generating and handling identifiers. The guidelines below provide details of how this should be implemented.

Implementing identity in many Devices is relatively straightforward, however for more complex multi-stage Devices (for example vision and audio mixers) there is more to consider. It is important that all editorial and transformative changes made to essence are represented by the identity model. As such, new Sources and/or Flows must be generated for a number of internal operations carried out by Devices.

In addition to the potential creative benefits of tracking identity, some operational tasks can be simplified. For example, a camera’s tally light can be instructed to watch for the ID of its video Source forming an ancestor of the vision mixer’s PGM Out Source, and switching on whenever this is the case.

Identity Hierarchy

Class diagram

All resources shown above are part of the JT-NM reference architecture. Each logical entity (aside from the Grain and its descendants) is identified by a UUID and a version, with the version changing whenever a modification is made to the resource’s metadata (such as a Flow label, Sender description etc).

Source and Flow Representation

Sources

A new Source should be created in the following circumstances:

Whenever a new Source is generated, its immediate parent Source(s) must be recorded. This is achieved via a ‘parents’ attribute in the Node API Sources resource. This contains an array of Source IDs corresponding to the Sources whose Flows have been brought together at this point. For example, a vision mixer which is fading between a Flow from Source A, and a Flow from Source B would indicate [“A”, “B”] in its ‘parents’ attribute for the duration of this transition.

Flows

A new Flow should be created in the following circumstances:

Note that in order to avoid creating a new Flow after every single processing element held within a Device, processing blocks can be logically grouped together provided it will never be possible to use a Flow from part way through the processing block. For example, a three band EQ block within an audio mixer will cause a new Flow to be generated. Creating a new Flow after each EQ band is an option, but as these Flows could never be used directly anywhere else internal or external to the Device the representation of it is of no benefit. It is however important to register the EQ process as a whole as a new Flow as it may be possible to route the pre-EQ and post-EQ essence to a Sender, or to a mixing element within the Device.

Sources and Flows must be advertised via a Node’s API, and registered via the Registration API if available. This should only be done on the Device which originates the Source or Flow; if a Flow is received by a Device from the network it does not need to be re-advertised via APIs.

Whenever a new Flow is generated, its immediate parent Flow(s) must be recorded. This is achieved via a ‘parents’ attribute in the Node API Flows resource. This contains an array of Flow IDs corresponding to the Flows which have been brought together at this point. For example, an encoder which codes a raw video Flow C into a coded video Flow D would indicate [“C”] in its ‘parents’ attribute.

Important Note: A processing element which has a 1:1 input to output relationship and doesn’t make editorial changes only need create a new Flow ID on output and not a new Source ID. As a Flow ID must descend from a single consistent Source ID, the Flow ID for these processing elements MUST be generated based on seed data including the incoming Flow ID. If this dynamic Flow generation cannot be achieved, the processing element MUST be viewed as a new Source instead (see Flow ID section below).

Identifier Persistence & Generation

Persistent identity helps to ensure that users’ expectations meet with reality. For example, if a piece of equipment is switched off and back on, the user would expect it to return with the same signals routed to and from the same ports. A control system managing this can only do so if the identifiers used by the Node remain the same.

UUIDs are used throughout the NMOS data model, and can be generated in a number of ways (including from hardware addresses) in order to achieve consistent behaviour (see RFC 4122).

Node ID

For physical Nodes, the Node ID must be universally unique to that Node, and remain the same for all time (much in the same way as a serial number).

For virtual Nodes, the Node ID must be universally unique to that Node. If a snapshot is taken of the virtual Node then it should be stored with the same ID, however the following conditions must be applied when re-deploying the virtual Node from this snapshot:

In order to simplify the above process for deploying snapshots, you may opt to generate a new Node ID for each instantiation of a virtual Node snapshot, but a mapping service must provide translations between old and new IDs as this may be required to keep session / production / automation data relevant.

Device ID

Owned by:

Should change if:

Should not change if:

It is suggested that Device IDs be generated using the combination of:

Source ID

Owned by:

Should change if:

Should not change if:

It is suggested that Source IDs be generated using a combination of:

Flow ID

Owned by:

Should change if:

Should not change if:

It is suggested that Flow IDs be generated using the combination of:

** This should only be used in cases where the generation of a new Flow ID has been the result of a 1:1 transformation such as an encode, and not a vision mix.

Sender ID

Owned by:

Should change if:

Should not change if:

It is suggested that Sender IDs be generated using the combination of:

Receiver ID

Owned by:

Should change if:

Should not change if:

It is suggested that Receiver IDs be generated using the combination of:

Virtual Identifiers

In systems which are heavily re-configurable such as an IT virtualisation platform, it may not always be possible to generate identifiers based on fixed hardware. This inability to re-generate the same IDs for the same processing elements indicates a need for some form of persistent storage in order to make the identifiers useful over a period of time longer than a single production deployment.

Consider for example a TV production using a re-configurable studio facility. The recording is split over a few weeks, with a gap of three days in the middle where the physical studio floor is in use by another production. It is necessary to ‘spin down’ the virtual infrastructure in use during this period so that it can be used by others. When spinning it back up again, all connections between senders and receivers should be re-instated, and all recorded metadata should be relatable to the previous recording period. By persisting the identifiers used in the previous production this is very straightforward (although the requirements for identifier re-generation as specified under the Node ID heading above should be observed, and mappings applied where necessary).

Real-World Identity Examples

In order to demonstrate how identity should be applied to real-world Devices, some example of common applications are included below.

Edge Device: Camera or SDI to IP Converter

Key Edge

System

Input

Output

Processing Device: Hardware IP Codec

Key Processing

System

Input

Output

Processing Device: Hardware Audio Mixer

Key Mixer

NB: A new Flow is created following each processing element where a tap off could be taken, even if it isn’t being taken at that moment. For example, a pre-fade version of Channel 1 may be taken to the monitor bus post-processing (EQ), so a new Flow must be created here. The key is to distinguish this Flow as different from the post-fade version which may not have identical content. If a Flow receives a time domain modification (Grain sync timestamp change, or delay applied), no data model changes are required as the Grain origin timestamps still uniquely identify it within the originating Flow. At mix points and where data is generated from a control signal (such as a tone generator) a new Source must also be created.

System

Channel Strip

Tone Generator

Delay Line

PGM Bus

Monitor Bus

During operation, as with any other fixed hardware Device there is little need to generate new identifiers as they can be baked into the Device at manufacture. Changes will however be required to the ancestry recorded against Flows and Sources within the API (and network registry if applicable). These changes will occur whenever a modification is made to bus routing, such as pressing a PFL button or linking a channel to a particular group.

Metering isn’t shown in this example, but may be shown to take an audio Flow as input, create a new metering data Source and Flow, and pass this data on to a Sender for transmission to the network as a series of measurements.

Processing Device: Virtual Vision Mixer on Fixed Hardware Node

This example covers a more flexible setup where the configuration of Devices is determined on a more freeform basis using logical processing blocks which can be assembled based on the user’s requirements. Fundamentally this works in the same way as previous examples.

Key VM-Palette

The user starts out with a palette of components which can be attached together to create a vision mixer suitable for their requirements. Each component can either have identity associated with it permanently (if there are a limited number of each component which can be deployed), or the identifiers could be generated on the fly as a particular component is instantiated. In the latter case, whilst randomly generated identifiers could be used each time, some degree of consistency may be useful. For example the main PGM output from the mixer might be best defined with the same Sender ID each time it is instantiated so that it can easily be brought up and routed from as part of a larger studio preset. Management and generation of these identifiers is at the discretion of the implementer, but a suggested scheme might use the Device ID plus processor type or role plus an index within the Device as the seed data to generate identifiers in a consistent manner.

Note as shown in the palette where new Flows are generated as opposed to new Sources. The video amplifier creates a new Flow based on its input as whilst it is editorially the same, an effect has been applied. The video matrix does not change any identity (no new Sources or Flows) as it acts purely as a passive splitter for existing Flows. The other components shown indicate that they are a new Source, either because they combine Flows or because they generate a Flow from scratch.

Having built a vision mixer from the palette above, a simple example layout is shown below.

Important Note: Unlike most of the processing elements above which have a fixed output Source and Flow ID, or carry the Flow ID through from the input, the video amplifier (much like an encoder or decoder) simply generates a new Flow from the input Flow without the need for a new Source. As a Flow ID must descend from a single consistent Source ID, the Flow ID for these processing elements MUST be generated based on seed data including the incoming Flow ID. If this dynamic Flow generation cannot be achieved, the processing element MUST be viewed as a new Source.

VM-Device

System

Inputs

Outputs

Pattern Generator

FX Keyer

←Data Model · Index↑ · Upgrade Path→

Documentation built at 05:12:15 CST on 2024-12-11.
(c) AMWA 2024. RAML/JSON licensed under Apache 2.0. Documentation licensed under CC BY-ND 4.0.