Vendor Content.

Multiviewer Considerations For The Multi-Platform Era

The concept of the multiviewer has been around for quite a while: to save cost and space in a monitor wall by using a single large screen to show a number of different video signals. For convenience, the individual signals in a multiviewer display are usually called PiPs (picture-in-picture) or tiles.

The first generation multiviewers were dedicated devices which took in SDI signals and output a fixed matrix: 2x2, 3x3 or 4x4. Some added the ability to add UMD-style labels to each tile, and to incorporate audio level bar graphs. Inputs were generally SDI: outputs were also HD-SDI, with some offering the possibility of spreading a matrix across two HD screens.

Such devices were fine for applications where the monitoring requirement never changed. But in dynamic broadcast environments, the ability to change the monitoring configuration quickly became important.

So, a second generation multiviewer architecture arose, where the hardware acted like a router, allowing the operator to put any input anywhere in the display. Indeed, some vendors offered multiviewers as plug-in cards for traditional routers.

They offered much greater flexibility, allowing display layouts to be changed from one template to another at the touch of a button. Users could add new templates by working directly with the device.

Today’s media centre is a very different place. Not only are there very many signals to track and monitor, they now come in multiple formats. Engineers and operators can reasonably expect to view, on the same display, not just SDI signals but live IP streams (as SMPTE ST2110, ST2022-6/7, or NDI).

It is also necessary to monitor distribution streams in multiple formats including HLS, MPEG-DASH and Smooth Streaming as well as MPEG Transport Stream and other “broadcast” outputs. There may be a need for some degree of signal quality measurement too, whether that be a waveform display or a data probe for stream monitoring.

In large implementations, like master control rooms, where it is impossible for a human operator to see detail in every one of tens or hundreds of tiles, you need to include alarms too, for conditions like picture freezes or audio silence.

Finally, engineers and operators have got used to the idea of having monitoring wherever it is needed, so typical broadcast centres will have requirements for large numbers of multiviewers. The nature of these will change regularly through the day: studio control rooms being used for different programmes; master control having changing shift patterns at different times; engineers needing to access specific signals during planned maintenance.

Increasingly, studios for news and magazine programmes will have a number of screens in shot on set, and controlling them with multiviewer technology is also convenient. That application underlines another definite requirement for multiviewers: not only must they offer excellent quality, but they must create the matrix with the lowest possible latency, so even when a screen is in shot it is responding instantly.

All of this can be achieved with the router-style of multiviewer, but as the requirements become more complex, the underpinning engineering becomes exponentially more challenging. To take an obvious example, if a signal is to be made available on a number of multiviewers, then it must be routed to every appliance. In SDI applications that needs significant router power and a lot of cabling. In an IP-based environment it means a very heavy load on the network which will cause response and quality issues.

To address these challenges, we need to consider a third generation of multiviewer. First, given the need for large numbers of controllers, the hardware needs to be simple and inexpensive, so all the functionality must be implemented in software to run on standard hardware, and preferably in the CPU without the need for GPU acceleration. For the systems architect, the multiviewer could be a dedicated appliance, software in COTS hardware, or a cloud instance.

This distributed architecture makes it very easy to scale. Each display is its own server, and you expand simply by adding servers. You can do this at any time up to any size whatsoever, with no need to forecast potential demand at the point of initial specification.

Another advantage of the distributed architecture is that you eliminate single points of failure. Should one multiviewer fail for any reason, there will be no impact on the functionality of the rest of the network.

The big challenge to be addressed though, is the need to make any signal available on any multiviewer display, without complicated and bandwidth-hogging cabling. The solution here is to turn the operation of the multiviewer on its head.

The traditional view is that all signals are routed into every multiviewer that might need them, then downscaled to the required size, then matrixed into the display. The solution for distributed architecture is to route each source into just one multiviewer (or a small number, for resilience), downscale them there, then distribute these smaller signals as required.

Intelligence in the processing will optimise the downscaled versions made available as they are demanded. There is no quality loss apart from the scaling to size, and the latency penalty is minimised.

By having a dedicated interconnection network the load on the main signal infrastructure is removed. Multiviewers can switch requirements at any time without impact on the primary signal distribution.

A central management layer for all multiviewers in an installation handles the screen layouts in each location. Each scenario can range from a single display up to 20 or more screens in a large monitor wall.

Marcus Ruoff, Rohde & Schwarz.

Marcus Ruoff, Rohde & Schwarz.

Designing, populating and switching multiviewers is also a software application, accessed by a standard web browser. Through the use of HTML5 the user interface can be fully visualised, with drag and drop design, yet be operated from any location with an internet connection, on any modern browser with no plug-ins.

As software-defined architectures become more prominent, so the central multiviewer control can also interface with network management applications or broadcast controllers. Automation can then control the timing and switching of layouts and signal allocations, as well as handling error messages and signal errors.

In an era of multiple input and output standards, huge numbers of signals to be monitored, and agile workflows calling for almost infinite operational flexibility, it is really important that users are supported by reliable, comprehensive monitoring which puts the right signals where you need them, without adding to the operator burden.