LAWO - vm_dmv Distributed Multiviewer (underlying Cluster Processing technology)
CATEGORY: Production - Processing
Lawo
Private Broadcast Cluster Computing with Lawo’s V__matrix vm_dmv Distributed Multiviewer
With the vm_dmv Distributed Multiviewer app, Lawo introduces the cluster concept for broadcast applications. Unlike Lawo’s vm_mv24-4 and vm_mv16-4 IP Multiviewer apps, which live on single V__matrix C100 processing blades, the vm_dmv is more bandwidth-efficient and infinitely scalable. It separates the multiviewer processing tasks into two distinct stages: input and output.
The input stage handles ST2110/2022 IP streams or SDI inputs, monitors them for video loss, audio silence and so on and outputs downscaled versions (LiveView streams) as well as their corresponding monitoring information to the network. The output stage, on the other hand, receives downscaled LiveView signals and corresponding monitoring data, generates and lays out the multiviewer head, handles alarming based on the monitoring data, and outputs multiviewer head signals as ST2110/2022 IP streams or SDI signals.
The LiveView information generated by the input stage can be consumed by any standards-based IP device. More details about the distributed multiviewer can be found on Lawo’s website.
The revolutionary aspect of the vm_dmv is that tasks are broken down into smaller assignments, which can be processed by a group of C100 processing blades in a cluster. Blades belonging to a cluster are referred to as nodes. One node acts as master and manages the processing tasks on all other nodes. The master is the single point of contact for systems used to control the multiviewer.
The master communicates in two different ways with the cluster. First, it establishes a connection to the websocket interface of every node for reliable exchange of vital data, such as cluster database and control information. Second, it sends out information like PPM data that does not need to be reliably transmitted on a specific multicast address.
The master distributes the tasks (LiveView creation, head layout and so on) among all nodes in a cluster, including itself. There is no fixed, pre-determined assignment of source processing or head layout to specific nodes. If the master becomes unavailable, another node automatically takes over. To facilitate this failover process, the cluster database is replicated to all nodes.
This cluster architecture is based on very low latency and high performance and has the potential to effectively handle live production. The infrastructure and technology for this cluster-based approach is already in place. The vm_dmv demonstrates that V__matrix-based clustering represents a giant leap forward for the broadcast industry and any application where efficiency, scalability and computing power are of the essence. Clustering is a layer that allows users to abstract the complete network infrastructure.
Cluster configuration
Some of the advantages of cluster scenarios are:
• Replaceable instances perform a given task. Users only need to care about the aggregate output.
• Clustering is inherently self-healing: suddenly missing capacity is automatically sourced from other cluster nodes.
• Ability to seamlessly scale up and down by simply adding or removing nodes in the cluster.
• Ability to prioritize, i.e. deciding which outcomes are more important than others. Processing capacity for important feeds is assured of the highest availability.
• Load balancing: any cluster member can take over some, or all, work from any other cluster member.
