The focus of this final blog in the series on broadcasting in the cloud is the publishing stage. This is where the transmission ready asset (prepared in the media services cloud or otherwise) is processed and delivered to the viewer.
In the case of non-linear (VoD) publishing to a connected device such as a PC, smartphone, tablet, smart TV or similar, the answer to the question of whether the cloud is suitable is one word – Netflix. The world’s largest VoD platform by usage is largely built on Amazon Web Services and many other on demand services such as Channel 4’s 4OD and the BBC’s iPlayer embrace the cloud model.
The more interesting question is whether the cloud is ready to support linear broadcast publishing – delivering live synchronous broadcast television to regular TVs via a broadcast receiver. To try to answer this question, it’s necessary to frame it correctly (no pun intended). Broadcast publishing, aka playout, in this context includes all of the components that process the already prepared asset and deliver it to a transmission network for broadcast: adding graphics, logos, mixing audio tracks, inserting subtitles and closed captions, sequencing programme segments and so on.
Traditionally, this is the domain of specialized hardware devices interconnected with baseband video over dedicated physical interfaces such as SDI. None of those characteristics lend themselves to the software centric, virtualised, IP connected world of the cloud. But there are significant changes underway in this part of the broadcast chain. Standards bodies such as the IEEE and SMPTE have developed specifications that aim to address the needs of professional video transport over Ethernet and IP networks (IEEE 802.1 AVB and SMPTE 2022-6 respectively) and these are beginning to appear in products.
The dedicated hardware devices that process video and audio in the playout chain are also evolving towards software implementations that, at least in theory, could run on standard hardware and so potentially run on the hypervisors that underpin the cloud. But just because we might be able to build broadcast publishing systems using virtually hosted applications, interconnected via IP networks, why would we want to? There are many reasons why this is a good idea and a full explanation requires more space than this entry allows so let’s just focus on one: software centric broadcast publishing can take advantage of the cloud as a flexible and cost effective operating environment.
At least that’s the theory. And in theory, theory and practice are the same, but in practice they are not. A key requirement for linear broadcasting is deterministic behaviour, the certainty that a frame of video will be processed in a very short and predictable timeframe along with associated synchronized elements such as the audio stream. The cloud, with its shared resource model, emerged like the Internet as a best effort service. High performance, yes; highly scalable, yes; highly flexible, absolutely; but strictly deterministic – sometimes.
In summary, the components of a broadcast publishing chain are evolving towards a model where they could be deployed in a cloud setting and the public cloud environments are also offering more deterministic performance than previously. Both seem to be on a path of convergence and this is a good thing. The true broadcast cloud seems to be on the horizon, but its distance is not yet clear.
Finally, it should be noted that many components of the broadcast chain do not require such stringent performance characteristics. Scheduling systems, automation systems and other core parts of the eco-system may be suitable for cloud deployment today, enabling new architectures and operating models. The cloud also offers a new range of capabilities that were often not viable previously, such as very large scale data processing, increasingly in real-time, that will allow more accurate and informed decisions for audience measurement, insight and targeting.
Broadcasters, and those that serve them, need to have their heads in the cloud.
Steve Plunkett, Chief Technology Officer.