Tuesday 10 August 2010

Broadcast workflows – the challenges and a REAL solution

Last time out I accused the supply market of using smoke and mirrors to confuse customers about IT-based broadcast workflows

Now I'm going to look at the real playout challenges and then reveal what I think the key to success is. 
My argument is based around this:


QUESTION: Can you reduce the complex requirements of modern broadcasting into a handful of computers?

ANSWER: Yes. But you must understand the workflow and meet the presentation requirements of complex channels.

The real challenges faced by channels and playout centres today are probably the following:



  • Integration,
  • Inter-operability,
  • Reliability,
  • Redundancy,
  • Having staff (and often systems integrators) that have a hybrid knowledge base of IT and broadcasting.
Making purchasing decisions in isolation would be another.

A final, and very important one, is thinking that they have to have a "best of breed" product for every element of their workflow.

It's a total misconception

Often channels and playout providers would be better off using 30% of the functionality of combined solutions rather than 5% of highly specialised ones.

Ultimately the key is expertise and understanding how a workflow fits together.

It's important to be able to know when to use and when not to use dedicated broadcast hardware.

Similarly, it's crucial to understand how to reduce costs and increase simplicity without reducing flexibility.

Right now, the broadcast supplier market is moving from proprietary broadcast application devices to standardised IT hardware and software.

And even when they claim not to be, the core of most products is IT based anyway.

The functionality of today's broadcast standard AV cards is not only good enough for other parts of an IT based broadcast workflow, they are often also at the heart of the majority of video server solutions, so arguments about not trusting your business to a PC with an AV card are null and void.

What is 'broadcast quality'?

There are also arguments about "broadcast quality" and how IT cannot meet this exacting standard.

Unfortunately there is no universally agreed definition of that term, and there are so many parts of a workflow that have an impact on quality, that it is more likely that no-one will be able to define the weakest link in the chain.

In my mind, "broadcast quality" is a term that should be applied to the quality of the moving pictures and sound, determined by the complete chain from camera to receiver.

So, whether you're looking at playout automation or automated playout, IT and broadcast equipment are determinants of "broadcast quality".

Which brings us to the important question: Do television channels and playout providers need application specific - well designed - "engineered" solutions? Yes.

But in my opinion this can be achieved with an expert mix of IT and broadcast equipment rather than by focusing only on the broadcast equipment.

Otherwise, going back to the Animal Farm analogy from last time, this is like saying "all animals are equal, but some are more equal than others".

Which might explain why some manufacturers create special labels like "premium" and "enterprise class".

Now, of course, any playout system has to be as close to perfectly reliable as possible. It must be capable of integrating into existing facilities. It must be flexible in operation with other systems. And it must be easy to install and maintain.

So what is the key to success?

To my mind it is:


  1. A combination of the systems integrator and the inherent knowledge of IT systems and the integration challenges these impose.
  2. Embracing open standards, cross company collaboration and implementing a mix of products to suit a workflow, not creating a workflow to suit a product.
Ultimately it is this that will determine the true attribution of value to the component parts of a project.

By doing this we can move away from describing projects as IT based broadcast workflows and, as the architectures continue to merge over time, just call them workflows.

It will also help users to move to a process of measuring price performance on a combination of initial cost, running cost, support, and future flexibility.

Which makes an awful lot of sense to me.