Clearing the Cloud- III

In the last part of this series, Andy Davies looks at how we can apply cloud infrastructure to broadcast applications.

Last month, we looked at the importance of virtual machines and how they have enabled a new public utility of cloud-based computing. This new utility has transformed the way IT companies deploy applications hosted on x86 server architecture allowing them to quickly deploy new software and services. More recently, vendors of broadcast technology have extended their use of the x86 Intel server architecture as they move towards workflows based on files.

In the early days, it was back room systems such as Traffic and Scheduling that made the most use of an x86 architecture. As Moore’s Law holds true and IT servers become ever more powerful, many of the broadcasting tasks, which historically have been handled by unique proprietary DSPs, are now able to be carried out, using software, on standard IT servers. If we look at the entire workflow of a typical publisher-broadcaster, we will find IT servers running applications at every stage of the workflow. Let’s now examine some of these key areas in more detail.

Ingest

Base band is always going to be a problem for a cloud-based platform. The whole point is that the cloud-based platform uses standardised interfaces such as CAT5 and IP, not broadcast specific standards such as SMPTE 424M. However, the direct ingest of media as files is now common place; this effectively negates the need for a conversion from the base band material.

If baseband is un-avoidable, then products equipped with Sony’s e-VTR interface and protocol allow a stream to be sent directly from the tape onto a network. Even live feeds coming in from live news or sports events can be accommodated. More recently designed DSNG vans and OB vehicles can deliver live material by utilising IP delivery protocols.  Often today when these signals get to the broadcast centre, they are converted to a base band SDI signal but this is often only to satisfy the needs of other legacy equipment.  In a total cloud-based system, this wouldn’t need to happen allowing the live signal to remain as a stream. 

Transmission

Even the complex functionality of a traditional broadcast chain including the video server, presentation, logo gen., graphics and ARC can be replicated exactly using software running on a generic x86 server.

The so called channel-in-a-box systems have already shown this concept to be true. There are even broadcast vendors selling solutions today, which as well as providing channel in a box services, also carry out the live encoding of the DVB transport stream (TS). This removes the requirement for the traditional PCI-based conversion cards and allows the software to be deployed in a virtual machine or to put it another way, in the cloud. Instead of a channel-in-a-box, we get the channel-in-the-cloud. The output from such devices is no longer coax cable and a BNC connector but rather uses standard routed IT infrastructure to deliver the encoded signal using UDP or RTP over IP. We start to now see the emergence of a “stream-based workflow” enabled by the underlying file-based workflow. It is the next logical step as the broadcast industry moves towards a generic base for its platforms. The broadcast chain becomes file-based or stream-based from end to end eliminating inefficiencies and enabling agile deployments.

The standardised agile channel-in-a-box software that we just described above can now be cloud hosted and created in an instant by broadcasters that have invested in the technology.

Think about a TV company that has just secured permission to transmit some major sporting event, perhaps, winning the rights from another competing broadcaster. This channel will need to create additional channels quickly and with minimum cost to ensure a credible return on investment. Today, this would be a major problem to any TV channel in this situation. They would have to ask themselves if they can afford the physical deployment of hardware? Can the services be built in time? Do they have the space to house the equipment in their existing buildings? What will happen to the new channels if they don’t manage to retain the rights in future years?

Using a stream-based workflow that can run on virtual appliances and provisioned using cloud technologies, this would be a much easier exercise. With our channel-in-the-cloud, we can use the online environment to order a new channel with just a few mouse clicks and a credit card.In the same way that the IT professionals we described in our previous article were able to create new MS Exchange servers in a few clicks, so it can be with broadcast professionals, creating a new channel by configuring options from the channel-in-the-cloud web site including aspect ratio, HD or SD, HD format, closed or open subs and RTP/UDP steam delivery point. After going through this process, the new channel can be automatically configured, provisioned, deployed, installed, tested and be ready for use within a few minutes of leaving the online checkout. This automatic provisioning uses the same data centre automation technology first utilised by Amazon to transform their business and enable innovation. The broadcaster’s operators would be able to access their thin client GUIs within minutes of the order being completed to start the work of uploading content, scheduling the channels, managing content, compliance editing, QC and ultimately controlling and monitoring transmission.

Uplink

Exiting the cloud infrastructure as a real time MPEG2 or MPEG4-encoded DVB-compliant transport stream delivered over RTP/UDP over IP, the stream-based workflow can be extended even to the uplink site. Already, broadcasters are delivering to their uplink providers using routed MPLS networks even though they may sometimes be unaware of it themselves. Through this type of routed infrastructure, the uplink site itself is effectively in the cloud and can receive DVB streams sent via RTP/UDP over IP for re-mux or uplinking directly to satellite.

Unprecedented Levels of Redundancy and Economic Disaster Recovery

The implication of cloud connected uplink sites is the ability to simultaneously route packets to two geographically separate uplink sites. These packets could be provided by virtual appliances dual hosted in two separate cloud domains which might be physically located in different continents. Even total loss of a broadcaster’s primary facility would not result in any significant loss of service.  Every “thin client” attached operator would be simultaneously updating both cloud domains keeping them perfectly in sync. In the event of a total facility loss, operators would only need to get access to the internet to continue their day to day operations. An entire cloud-based broadcast operation could be running in a disaster scenario from a handful of downtown coffee shops with good connectivity (and good coffee obviously)! 

For broadcasters wanting economical Disaster Recovery (DR), the second cloud domain doesn’t even need to be active, simply springing to life when required. The decision to spring to life can even be automated based on the loss of other services. Cloud resources are only paid for when they are consumed and then are usually billed by the second. The astounding thing about this approach is the ability to have disaster recovery that you only pay for when you need it. Contrast that approach with today’s prohibitively expensive DR sites; sites that, although necessary, are often not implemented due to cost and return on investment issues.

SYSTEM INTEGRATION 2.0

The technology, software and hardware to provide the above services and solutions already exist today. This is no pipe dream based on theoretical hyperbole but is rather based on a set of technologies that are already in use, implemented and well tested in isolation. So why don’t we see large scale cloud-based channel playout centres today? 

The missing link at the moment is not some crucial piece of technology or fundamental constraint that needs to be overcome although there is work to be done in some areas. The missing link today is a next generation approach to systems integration that will bring these isolated technologies together into a coherent whole; systems integration 2.0 if you will. 

There are already systems integrators that are leading the way in this field. Fuelled by their recent successes in implementing file-based workflows, they are armed with the network design capability, the deep SOA knowledge and the detailed understanding of software development to lead the next generation of systems integration into a future of stream-based workflows. 

Andrew Davies is business development manager at TSL Middle East.