The “Second Wave” of IP refers to decoupling processing capability provided by apps from the hardware they run on. The aim is to allow users to leverage different processing tools, possibly from various manufacturers, on the exact same IT server, or indeed in the public cloud, throughout the day, which is why advocates of this initiative like to refer to this approach as the “Dynamic Media Facility”.

It is the perfect illustration of the agility operators enjoy for building their technology stacks for an upcoming assignment, which can be anything between transcoding incoming streams or signals, processing during a production, adding graphics, all the way to preparing the required delivery formats for the various playout platforms, and MCR monitoring/quality control.

All processing routines solicited for these diverse tasks are thus no longer provided by dedicated hardware devices, many of which are one-trick ponies, but by commercial off-the-shelf (COTS) servers supplied by Dell, HP and others. The reasoning behind this approach is that IT technology is evolving so fast that it no longer makes sense for broadcast and AV vendors to split their R&D efforts between designing cutting-edge feature sets and building the hardware that does the number crunching.

Of course, most bespoke hardware released over the last few years can be considered a computer whose functionality is determined by the software it contains. So why would anyone want to switch to servers from a third party, or a public cloud, whose behavior can only be controlled up to a point? The main reason is that the envelope of IT processing power is being pushed at a relentless pace. Keeping up with the state of the art in IT requires dedicated R&D teams and order quantities that would justify entering into price negotiations for the required CPUs and GPUs. No broadcast vendor comes even close to something that might be deemed an economy of scale, while NIC bandwidth requirements, the number of processing cores, and many other technical aspects evolve in leaps and bounds.

In all fairness, there is not much about a server’s or the public cloud’s behavior that operators need to control. If anything, it should be the other way around: the processing apps need to adapt to the hardware and comply with OS specs. Or do they? This is precisely why Lawo’s HOME Apps have been designed to be containerized microservices: unlike virtual machines, containers require no bespoke operating system. Moreover, thanks to the container approach, each processing step can be a sovereign island that is open to partnering with other apps, to allow operators to create processing chains—also referred to as tech stacks: transcoding, up/down/cross conversion, color correction, delay adjustments, etc.

The absence of a dedicated OS means that there is no need to run all processing steps within the same operating environment, while connecting one container to the next does not entail leaving one OS before entering the next in order to get to the next app. Such steps inevitably require time that induces latency. The containers’ island nature moreover means that, in the event of a malfunction, only that specific container is affected, while the others usually remain fully functional.

Additionally, thanks to the HOME management platform, it will be possible to switch to a redundant processing path, picking up from where the troubled path left off from a second server. By default, updating HOME Apps means that newer versions of the required apps are simply added to the existing pool, offering operators the choice to revert to a previous version if that is more convenient.

Next, since Lawo’s HOME Apps evolve around microservices, i.e. modular building blocks that each play a specific part in the process, shared functionality, such as inputs/receivers and outputs/senders, etc., resides in separate containers (roughly one per stream) that are connected to the processing app proper. This has been a deliberate choice, because inputs and outputs are the same for all HOME Apps and only need to be updated once when new functionality is added.

Audio and video engineers working on a project are not necessarily aware of these inner workings, because that knowledge is of no consequence to their activity: they simply choose the functionality they need, specify the input and output formats as well as a few other aspects via intuitive drop-down menus, and get on with their job.

Run Baby, Run

HOME Apps running on COTS IT servers also allow users to shift their processing functionality around: broadcasters and production service providers are free to use HOME Apps both on-premise and remotely—to local production hubs or OB trucks. Processing capacity that is not needed at the mothership can thus be transferred to a production team that covers an event elsewhere: a sports venue, a concert or opera venue, on election days, etc. Doing so does not necessarily mean that the servers on which the apps were originally installed need to be shipped to the site where they are needed. The remote production location or OB truck can have its own servers with a full complement of HOME Apps. Yet, since these apps are only used occasionally, purchasing perpetual licenses for them would cause the same headaches as the issue they were, in part, designed to cure: chronic underutilization.

This why a flexible licensing system by the name of “Lawo FLEX” was developed, precisely to keep the app mobility described above manageable, both from a financial and a technical point of view. While users are free to purchase perpetual licenses for all HOME Apps and effectively “own” their software-based processing pool, they can alternatively embrace a Flex Subscription Credit system. With a validity of one month, one year, or up to five years, these credits are managed centrally, allowing an administrator to allocate some of the company’s credits to an OB truck that covers an outside event via a convenient administration platform, for instance.

In this way, all operators on prem and inside the OB truck benefit from a powerful processing pool at a cost far below what they would pay for perpetual licenses for each and every app in each location. The purpose of credits with a validity of one month is to allow broadcast outfits to boost their processing capacity for a limited time, such as an international sporting event, a music festival—anything beyond day-to-day business for which there are probably enough credits, or perpetual licenses.

Platform-wide Agility

Developments are underway to further shrink the server real-estate required by operators who wish to remain vendor-agnostic. Most broadcasters and production service providers currently favor privately managed (and controlled) COTS servers over public cloud workflows because of the perceived security and operating cost benefits private servers bring.

There are plans to run apps by different vendors on the same GPU or CPU.  They rely on a concept called “shared memory”, a feature that allows server threads and processes to share data by common access to pools of memory. This reduces memory usage and disk I/O, allowing for high-speed communication between processes.

Thanks to this approach, operators will soon benefit from multi-vendor platforms for their processing requirements where desired. Meanwhile, Lawo’s unified HOME platform already offers stunning synergy effects all by itself. These are based on combinations of several software apps with Lawo hardware.

An essentially software-only example involves the VSM broadcast control system and the HOME Downstream Keyer, Multiviewer, Color Corrector and Stream Transcoder apps to build (drum roll)… a virtual video switcher that can be controlled via a touchscreen and/or hardware panels.

Another application, the Intelligent Multiviewer, is built around the HOME Multiviewer and theWALL apps, a .edge IP gateway with edge-processing functionality, and Lawo’s HOME management platform that supervises the magic in the background. Starting with software release 2.0, .edge is able to generate three proxies of any video input signal at 1/4, 1/16th or 1/64th of the original resolution. With the theWALL app, users configure their multiviewer layout for the HOME Multiviewer app, choosing the sizes of all required PiPs. In most instances, multiviewer PiPs have different sizes, so sending the 1:1 picture to a small PiP is a waste of bandwidth. This is why the HOME Multiviewer app has been equipped with a resolution-aware “dynamic receiver”. Depending on the PiP size, the multiviewer automatically selects the resolution (original or one of the three proxy flavors) that best matches the PiP in question, based on the prerequisite that a proxy must meet, or only slightly exceed, the required PiP resolution. Smaller sizes mean that fewer megabits need to be transported, freeing up bandwidth for the transport of other streams.

Finally, Lawo users are increasingly able to choose between a hardware and a software incarnation of a given processing functionality. Combinations of both whenever the processing heft needs to be stepped up are also possible, of course. The A__UHD Core audio processing engine, for instance, now has a HOME mc² DSP App companion that feels, sounds and responds just like the hardware DSP, allowing operators to spin up an app instance when more audio processing is required and purchasing an additional A__UHD Core would not make sense. More such hybrid platform solutions will be announced soon.

Getting There

Broadcasters and production service providers are clamoring for ways to make their lives easier. Intuitive user interfaces and a platform where all parts, together, produce the ideal outcome for every workflow application provide a solid foundation for this. And tomorrow’s way of interacting with the processing tools might very well differ from today’s.

Adding maximum agility to the mix in the ways described earlier empowers production teams to produce more with less—with confidence.