Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Can we define a ‘channel in a box’ in a broadcast workflow?

Over the last few years IT-based playout and automation systems have become more common. The term ‘channel in a box’ has also been gaining favour and momentum, without much discussion or consensus about what it actually means, writes Mark Errington, Chief Executive Officer, OASYS.

Over the last few years IT-based playout and automation systems have become more common. The term ‘channel in a box’ has also been gaining favour and momentum, without much discussion or consensus about what it actually means, writes Mark Errington, Chief Executive Officer, OASYS.

I would like to think that as manufacturers, we have a duty to educate as well as innovate, so here is my attempt to compare the generic products available in the market, the key components of each, how they fit into an IT-based broadcast workflow, and see where there is common ground — while analysing most specifically what is a ‘channel in a box’.

A broadcast workflow is broadly made up of the following:

  • Creating material
  • Indexing and managing the material
  • Assembling the material for linear and nonlinear playout
  • Distributing the material to customers
  • Recording, logging and monetising the content

An IT broadcast workflow is where material is stored in files, and where some or all of the broadcast workflow stages are automated by computer software. A sub-set of this is playout, and a sub-set of that is automated playout. Let’s start here.

Automation of workflows grew out of the control of broadcast devices, like tape recorders. Computer software was developed to send commands to these multiple devices, assembling the output of each of these devices into a final output. This type of automation is still widely used, and it still fits into an IT broadcast workflow model. I will call this Playout Automation.

Other software was developed for other types of automation, such as asset management, storage, re-purposing, staffing, recording, scheduling etc, but these can be common to all types of playout.

So as an alternative to Playout Automation, other software evolved at the same time, but instead of sending commands to multiple devices, commands are primarily contained within the system (or sent to only one system) which completes the assembly of the final output inside the ‘box’.

The majority of broadcast features can be included inside a system; depending on the channel requirements, some processes (such as live input switching) have to happen outside the system, but the majority are self contained. So I will call this Automated Playout.

In Playout Automation and in Automated Playout you have a ‘box’. In Playout Automation it is generally just a control PC with no input/output capabilities. In Automated Playout it is a computer consisting of: a power supply; a motherboard; CPU/Memory; system and storage drives/controllers; network interfaces; and an input/output card.

What makes each box different is the type of input/output card – hardware features, software features, and the processing power available from the various components. This is a broadcast server – not a video server which only handles audio and video, and why in a Playout Automation solution the assembly is done in a Switcher/Mixer.

Running a channel
So given that a Playout Automation solution needs multiple devices to assemble the output, it could never be described as a ‘Channel in a Box’, although many component parts are IT-based. Automated Playout solutions could be a ‘channel in a box’, providing both the client and server software resides within the single system and assuming the processing power is sufficient to cover all the IT broadcast workflow stages.

The server software is that which carries out the commands, while the client software issues the commands. The client software can be either integrated in, or installed on the broadcast server.

So what defines a ‘channel in a box’ is whether you can digitise, edit, store, manage, schedule, play, record and monetise assets on a single device. While this is possible, it is not necessarily wise.

If you take out the other aspects of running a channel, you could get ‘playout in a box’, and that actually fits much more neatly into an overall IT workflow: then it is just a case of how many features (hardware and software) does the box perform, and how many other pieces of equipment – whether IT or broadcast based — are required for a channel solution.

As playout is only a sub-set of an overall IT broadcast workflow, the functions of each playout device therefore only define how the final content is assembled for distribution. In a linear channel you have a spectrum of how many devices are required for final assembly, and a highly featured broadcast server requiring no live inputs is at one end of the scale, handling video, audio, graphics, branding, sub-titles, aspect ratio and many other things. At the other end of the spectrum is Playout Automation with a mixer being fed by video servers, graphics servers, logo generators, converters, etc.

Wherever your solution is on this spectrum, however, it is usual to have many other factors in your channel workflow. Asset management and workflow management systems often over-arch some or all of these, but some are made up of a range of processes ranging from manual to fully software controlled, often with software integration links between various supplier solutions.

It therefore stands that as the final broadcast output will look the same, the only elements you need to look at in deciding the correct workflow for your channel are the commercial ones.

  • Cost: Is IT equipment less expensive to acquire and maintain than broadcast equipment?
  • Redundancy: Can you minimise the number of devices?
  • Deployment: Can you install and expand/contract quickly and efficiently?
  • Feature development: Can you implement new features more readily in hardware or software?
  • Performance: Are systems stable and well supported, and how many support relationships do you need?

Are IT broadcast servers capable of handling multiple file formats, HD, complex graphics, mixing, scaling, sub-titling, streaming and logging? With the increase in processing power in the last five years, absolutely yes.

Is there a workflow that is not suitable for this type of playout? No. Is this therefore the future of broadcasting? As software becomes more sophisticated and more processes become software — rather than hardware — dependent, and as more archives of material are transferred and maintained as files, it is likely that IT broadcast servers will not even require input/output cards. As processing power increases, the capabilities of the servers will increase, so you could put many more functions into a single system — meaning the workflow could really become a ‘channel in a box’. For now, however, ‘playout in a box’ is much more of a reality.

And when you are looking for your solution, avoid the hype and ask just how many functions the broadcast server can perform and how many additional pieces of equipment you will need, because that will help you to properly address the commercial aspects of your choices. Look at the common areas – storage, import/export, workflow management — and see that the architecture of the systems is very similar in all IT-based solutions.

Then look at the knowledge base of the suppliers and their operating history of delivering software-based solutions, and cross-company integration. Some manufacturers will claim to have invented IT-based broadcast workflows and automated playout in the last few years. In reality, software solutions have been available for decades, but it is the increase in computer (IT) processing power that has pushed automated playout into the mainstream — and it is here to stay, whether it is really in one box or not.