Page Comparison

...

MCM9000 uses different API for different use-cases. Please refer to the appropriate APIs described below while using or integrating them with your system.

API 2.0

The GUI of MCM9000 and its functionality are built upon API 2.0. The key element here is that all indexes are numeric based (i.e they are based on id’s). It reflects the internal database structure.

API 3.0

API 3.0 is specifically designed for standard multi-viewers, and hardware multi-viewer.

Initially, API 3.0 was used for uncompressed, which is an asymmetrical relationship between the number of channels the system monitored and displayed since the system does both probing and displaying. However, in hardware multi-viewer, it is a symmetric relationship, in which the channels are not monitored but just displayed.

API 3.0 was implemented in order to automate the behavior of the system to control visualization. For instance, a channel is being monitored in the background but not displayed, in such case the channel needed to be set on the output tile. API 3.0 maps channel to output, (i.e) the channel is assigned to a tile and internally we generate the channel configuration and assign it to the tile. While removing the channel, it is deleted from the tile.

API 3.0 combine the two steps internally, channel configuration, start monitoring, and assigning it to the tile.

** API 3.0 is useful only when the system is automated by a third party.

API 4.0

API 4.0 is specifically designed for broadcast controller integration. It replicates some behavior of NMOSbefore it existed, such that the configuration is based on senders and receivers.

While configuring the uncompressed channels, the components (2110/2022 video, audio, etc.) are added. API 4.0 generates a template to control the channel that includes the video, and audio components. API 4.0 is based on UUID and not ID. UUID is exposed externally and is associated with components that are essential for the receivers.

**Please note that the integration is based on receivers and senders API and it is applicable only when you have a broadcast controller integration.

Also, the system is static (For example, a multiviewer that has a preset configuration and can’t be changed), and doing integration based on API version 4 with the broadcast controller there is no ability to implement resource management.

MCS and API 5.0

API 5.0 is specifically designed for MCS functionality. Although, MCM9000 also shares most of the API 5.0 as MCS, there is a difference in their functionality such as,

• MCM9000 uses stacking functionality to certain extend.

• Statistics in MCS are pushed through Redis database, however, some of the statistics are not yet implemented on MCM9000.

Importantly, API 5.0 is much relevant only when MCS and MCM9000 are connected and you interact with MCS.

**To interact with MCM9000 when it is not integrated to MCS, please use API 2.0 and not API 5.0

Please note all out API’s are Json based and open for changes.