TAG VS – Multiviewer & Probe Management

Thomas Gunkel

This use case shows typical examples of how DataMiner can interface with multiviewer and probing solutions. In these examples, DataMiner interfaces with TAG’s MCM-9000 platform covering three typical scenarios:

• DataMiner Dashboard: Receives parameters and KPIs from TAG probe (transport layer, SCTE triggers, audio/video content monitoring, etc.).
• DataMiner Control Interface: Multiviewer control (e.g. input switching and layout change).
• DataMiner Service Monitoring and Automated Issue Resolution: DataMiner monitors a redundant transmission service and all its infrastructure, pushes info and DataMiner alarms to multiviewer mosaic (UMD and Tally control), and automatically switches to a backup service.

USE CASE DETAILS

Use case 1: Get real-time access to all parameters and KPIs that a TAG multiviewer/probe exposes (stream bandwidth, jitter, video freeze, loss of audio, and much more), and tailor your DataMiner dashboard to your needs.

Use case 2: Change multiviewer inputs and change layouts on a TAG mosaic output. In this example, an HLS player is also embedded right into the DataMiner control interface.

Use case 3: DataMiner monitors a redundant service and all infrastructure that belongs to this service (e.g. cameras, encoders, IP gateways, changeover units, etc.). DataMiner tracks which service (SRC1 or SRC2) is currently on air (Output). DataMiner knows which channel is live and which one is on standby and pushes that info as UMD labels ("LIVE" and "STANDBY") to the TAG multiviewer. TAG's Tally functionality is used to color-code the text (RED to indicate PGM tally). A second UMD label is used to show the overall service health state, which is calculated by DataMiner on the multiviewer. DataMiner knows which channel is live and which one is on standby and pushes that info as UMD labels ("LIVE" and "STANDBY") to the TAG Multiviewer. TAG's Tally functionality is used to color-code the text (RED to indicate PGM tally). A 2nd UMD label is used to show the overall service health state that is calculated by DataMiner on the Multiviewer.

This control interface has been built for demo purposes, so it contains action buttons to generate an alarm on the SRC1 service, which is currently on air. Click the button and DataMiner will receive an alarm. In this case, this will be an overheating device on the SRC1 service, which is currently on air and immediately pushes this critical alarm onto the multiviewer mosaic. In other words, even if operators in the NOC or MCR do not have the DataMiner client open, where they would certainly get notified immediately, they will still immediately see the alarm on the multiviewer wall. Alarms can also be used to trigger a set of activities to automatically resolve the issue. DataMiner's Automation engine is used for that.

Following on the critical DataMiner alarm in the SRC1 service, DataMiner triggers a script to automatically resolve the issue. In this example, an API call is sent to an ACO (active changeover unit) to switch the output from SRC1 to SRC2. You can now see the "STANDBY" label on SRC1. The "LIVE" label has moved to SRC2, and tally colors have changed accordingly. The Output tile also shows the "SRC2" UMD to indicate which service is currently on air – all controlled by DataMiner. Neither the ACO nor the TAG probe, with their capabilities to analyze video and audio streams and to detect for example a video freeze or loss of audio, would have detected a problem within the service infrastructure like this device overheating example. DataMiner also receives all alarms from the TAG multiviewer acting as probe and would execute the exact same Automation script to resolve the issue. Combining DataMiner with probes and multiviewers such as the TAG platform makes sure that you can no longer miss any problem, be it an issue with the signal or any other problem within your infrastructure.

And finally, after the overheating problem has been resolved, the alarm will disappear and DataMiner can initiate an Automation script to switch back to the SRC1 service.