The new video bridge works on compressed and uncompressed content and doesn’t work on a stacked system. Thus, the new bridge is relevant only while working with MCS, which manages multiple MCMs.
For example, one MCM needs to show content that is monitored on the other MCM. The MCS is configured either through a CED or not through CED or a persistent display. It configures a display of a channel on a different unit than the ones that it's monitored on. The MCS is configured to the tile definitions of the bridge, (i.e.) the URL of the original source and from this point, the MCM creates a mock-up channel for the bridge and allocates this channel to the tile. These mock-up channels are seen only on MCM and not visible from the MCS side. The different work models of the video bridge are as follows.
For a Compressed and SPTS/MPTS stream, it takes the original channel, which is compressed, and transfers the content.
For an OTT stream, repackage the TS, so the content is not encoded. However, the video quality is not lost.
For an Uncompressed stream, the bridge is meant to handle uncompressed content or ndi contents. The compression is according to the tile assigned (i.e) the resolution and bandwidth will be reduced according to the tile’s need.
is designed to efficiently share souces between multiple instances of MCM - may they be physical, on a VM or in the cloud.
It works on any type of stream supported by the TAG system and requires MCS controller, as it is the brain that identifies whenever a source is requested to be displayed on another MCM than the one that’s probing it and dynmaically creates the temporary bridge channel to transfer the stream, and then shutes it down when the stream is no longer displayed on the remote MCM.
There are a few modes in which the bridge works, based on the scenario:
1. If both MCMs are installed on a VM or physical server then it will work in a “TCP mode” which means that the source will be compressed and wrapped in TAG’s propietary compression and sent to the remote MCM.
2. If at least one of the MCMs involved in the bridge transfer are installed on cloud the system will automatically recognize that and wrap the compressed stream in SRT, to share it more efficiently and securely.
3. if the source that needs to be sent over the bridge is in “light” or “extra light” monitoring mode then there will be no decoding and compressing of the stream, it will be sent “as is”.
The bitrate of the re-encoded bridge channel (in scenario 1 and 2 mentioned above) will be affected only by the following parameters:
1. SOURCE frame rate
2. TARGET tile size, meaning the size of the tile in the remote mosaic where the source needs to be displayed.
Amount of movement in the video frames, as with any compressed stream.
Important notes:
Source type, bitrate and resolution have no affect on the bridge channel bitrate, meaning, if you’re transfering a low quality compressed stream through the bridge it’s very likely that the bridge channel bitrate will be higher than the source, since the compresseion we’re using has lower compression ratio then MPEG2, H264 and especcialy H265, but it is much faster then any of those other codecs to maintain lowest latency possible.
The bridge channel’s maximum resolution is 1920X1080, so the bitrate will be identical if you’re trying to display it on a full screen HD output, full screen UHD or 1/4 UHD.
The bridge channel will consume up to 5 points from the server generating the mosaic, not the one generating the bridge channel.
Here’s an estimation of the bridge bitrate based on the source frame rate and target tile size, these numbers are flactuating by about 20%.
...
** The new bridge on MCM9000 is available from version 6.0 onwards.
How to configure the bridge on MCS
In this example, two MCM systems nodes are configured on MCS for a video bridge. The first is the monitoring system, and the second one will be the displaying system for the video bridge.
** Please note a minimum of two MCM is required to configure the video bridge through MCS.
Physical MCM 1 will be the one generating the mosaic on which we plan to display the source and Physical MCM 2 is the one who will be probing the source.
On the MCS navigate to Devices Management page. Please ensure atleast two MCM9000 devices are configured on the MCS. Please refer to Adding MCM9000 devices to MCS to configure MCM9000 devices, make sure they’re both running the same version.
In this example, first device MCM-9232 is used for monitoring Sources and second device MCM-9898 is used for displaying on the Output mosaic. 
Ensure that the Video Bridge is enabled for the right NIC in the interface configuration:
Go to “interface configuration” tab, double click on the interface through which you want the bridge traffic to be transferred, and check the “bridge” box.
It can be any type of NIC supported by TAG.
You can have up to two NICS per MCM with bridge enabled, in case one fails at will automatically switch to the other one.
NOTE: network names of the NICS used for the bridge traffic MUST BE IDENTICAL.
...
Please refer to Add sources to through MCS to add Sources and Configure Output Encoder on MCS to configure the Output Encoder
...
.
...
Navigate to Sources Configuration and monitor
...
some sources on
...
Physical MCM 2
Go to “layouts” tab, or use operator console in, order to assign these sources to a layout.
Navigate to Output Configuration and
...
Now goto the second device (MCM-9898) that is displaying. Here in the Sources monitored are in the Bridge as shown below.
...
...
activate an output on Physical MCM 1.
In the output’s “layout” tab (or using the operator console) assign that layout to the output generatd by Physical MCM 1.
Open the preview sceen of the outputs and see the bridged source are active
...
The only place where you can see the Bridge channel created is on the MCM “source configuration” tab.
...