Broadcast Beat Magazine 2016 NAB NY Special | Page 64

media production facility has a natural diversity of uses, with different services and processes peaking in their demand at different times of the day or week. In a conventional SDI system, some expensive equipment is required quite infrequently. A good example of this might be Standards Converters … specialized devices which are often used only a few hours each week, or they may be used extensively during a specific event such as the recent Olympic Games in Rio. In a software defined architecture the servers which run standards conversion services can host other services for the rest of the time, thus reducing the overall equipment requirement and the associated air-conditioning load and power consumption.

Users can also take advantage of cloud computing services (either private or public) to enable swift dynamic scaling of resources to match business demands, though it should be understood that software-defined architecture does not depend on cloud computing. In fact the entire topic of cloud computing for media - its benefits, implications, costs and challenges- requires in depth discussion on its own merits. However, it is the software-defined nature of the architecture that allows it to be virtualized.

The planning challenge

For the broadcaster’s system designers, planning for a software-defined system is more complex than for conventional systems. As a simple example, if you are designing a linear SDI system, it is relatively simple to calculate what size of video routing switcher is needed. You count inputs and outputs and add some spare capacity. You can be certain that every cross-point and every path can be used simultaneously. For an IP based software defined system however, you will require detailed knowledge of work patterns, peak loads, concurrency of events etc. to determine the correct scale of the system – the number and class of servers, the size and bandwidth of storage, the capacity of IP routers, the number and type of software licenses etc. – and at some stage a business decision is often required to arbitrate on compromises between cost and capacity to be designed into the system.

Unlike SDI systems, software defined systems cannot yet be considered as “plug and play”, even though various standardization efforts have made great progress towards this ideal. Therefore it is incumbent on the end user to proceed with due diligence and conduct thorough tests of the proposed solutions with their own signals and files, before putting any new software into production. All manufacturers should be able to provide indicative benchmark test results, but definitive system scaling is often possible only once a solution is in “the real world”. This scenario presents a challenge that a system like Vantage can solve. On the one hand, standards are needed and on the other hand, Vantage can be the “glue” to enable disparate systems to work together.

Once your solution is up and running, any broadcaster should have a “sandpit” test environment for pre-production testing of new software versions. Ideally, any production software should have tools to manage version control, or at least to make it simple to roll-back to a previous version should unexpected problems occur.

Integrating IT

technologies within broadcast investment cycles

The IT industry brings economies of scale and rapid development cycles but this also means that equipment life cycles are much shorter than for conventional broadcast products, and users must plan for replacement cycles of three years, rather than the usual five years (or more) they may be used to. This has implications for the depreciation costs and replacement costs of any equipment. Another factor which has changed from the days of dedicated hardware is that users should budget adequately for software maintenance contracts. Any software defined system is, by definition, dependent on the reliable performance of the chosen software. Neglecting software maintenance is as damaging in the end as failing to change the oil in your car.

64