Is channel in a box dead?
Maybe a better question would be “was channel in a box ever a real thing?”
In truth, so-called channel in a box systems were always channel-in-many-boxes. The box might have contained a bit of local storage, some primitive graphics and a simple switcher. But somewhere else you needed sophisticated 3D graphics generators, multi-channel planning and scheduling systems, and an overarching asset management and storage network.
And the commercial hook for the channel-in-a-box unit was that it was essentially a standard PC running some nifty software. Does that sound familiar?
Today, we expect virtually all of our broadcast and electronic media tools to be nifty software running on standard COTS hardware. And we expect it to be rather more sophisticated than simply providing basic playout of a single channel.
What we need from playout automation is agility. We should be able to select the functionality we need for what we are doing. For example, we might want simpler graphics for the mobile version of a channel but more sophisticated graphics on the broadcast output.
Which implies that we can create multiple versions of a channel, not just one. And, of course, multiple versions of multiple channels.
Given the power of today’s COTS hardware, and smart software like Gallium PLAYOUT from Pixel Power, then you can expect to run channels in a box. You can expect high efficiency through virtualization: only allocating resources when you need them.
Some vendors are currently making a great deal of fuss about “micro-services”, as if this is the latest, greatest thing. Essentially, it is another way of talking about virtualization, where instead of building a fixed architecture to do a job – for example to provide a playout channel – you load the various software functions that you might need into a standard server platform, then you are free to use just the instances of each piece of software as you need, when you need them. It’s a little like the hardware ‘glue’ we used to talk about but today we like to call it ‘Virtualized Glue’!
Virtualizing the operation means that resources can be shared, provided the orchestration layer is well designed and managed. Those 3D graphics can be created automatically, minutes in advance, to minimize the use of the 3D license and the processing power it requires.
What box is your channel in, then? Well, it is up to you. You can have a blade server or two in your machine room to provide the automation functionality, and in all probability other applications too.
Or, because it is virtualized, you can rent processing space from the IT department and put it in a data center, on your premises or in a dedicated facility. Moving it off site, though, depends upon connectivity. That connectivity has to be secure and it has to provide guaranteed bandwidth at a low cost.
Traditional broadcast engineers would always route mission critical signals over (a minimum of) two geographically diverse routes. Just because the wires are carrying IP data rather than SDI video, are you suddenly going to lower your standards? Any external connectivity has to be of guaranteed capacity and fully redundant.