Content delivery has evolved radically in a short space of time. The fast pace of change has come as media companies have sought to move large parts of their operations from the traditional broadcast setup to a more cloud-based environment. However, this has led to the technical requirements of delivering content over IP not always being clearly understood. As a direct result of this, not all content is being delivered at the required broadcast-grade standard. Quality is being compromised unnecessarily and this has the potential to be damaging for the industry as a whole.
Two feeds a world apart
As live internet streaming on platforms like YouTube and Facebook Live became more popular, an assumption that all content could be delivered over IP using the same mechanism prevailed. That assumption couldn’t be any further from the truth. The technical requirements for delivering content for streaming are different from the technical broadcast requirements for live linear delivery.
Let’s say a content owner wants to share a live feed on YouTube. Social platforms have been designed to make this type of live webcast as straightforward as possible, compressing audio and visual data into a consolidated package. But what happens when the content owner decides that they also want to share that same feed with international broadcasters for distribution? Unfortunately, it isn’t as straightforward as simply sending the same feed to a new set of takers. In this scenario, the only thing that will ensure broadcast-grade content requirements are met, is to establish a new feed either from source or manipulated from the original. Separate feeds are needed for different purposes, and broadcast feeds have a host of technical requirements. These additional considerations include, timing, multiple audio tracks, correct audio codecs, frame rates for different locations, and interlaced vs progressive, to name a few.
Understand limitations
Another common misconception that can muddy the IP waters, is that equipment that uses certain protocols, such as SRT and Zixi, will deliver broadcast-grade content. That is simply not correct. What many people do not realise is that even if an encoder and decoder use the same protocol and are compatible with each other at the transport level, they are still not guaranteed to deliver a broadcast quality feed or even be compatible at the encode/decode level. The capabilities of the hardware and the criteria set by the engineer, have much more of an impact than the protocol that is used. I’ve heard comments like “we use SRT as we typically get a lower latency than Zixi” but this demonstrates a lack of understanding of transport protocols and how they function. The latency on an IP feed is based on the figures set by the user for the receive buffers, not the protocol that has been selected.
The proliferation of hardware on the market that boasts support for certain protocols probably hasn’t helped matters. Often, much of the equipment out there that supports the core transport protocols will not be suitable for broadcast workflows. You don’t have to look hard to find plenty of encoders that offer support for SRT but are still unable to provide MPEG audio or multiple audio channels, which is a basic requirement for broadcast workflows. The key thing to remember is that using the same label at both ends, does not guarantee that the package being delivered is fit for purpose.
IP as a broadcast engineering speciality
There is a definite lack of understanding across the industry regarding IP protocols and how broadcast IP workflows operate. The root cause of this is probably that content delivery requirements and mechanisms have changed so quickly over a short space of time. This has not allowed skills and industry expertise to keep pace. Broadcasting has alway been a complex field and as such, it has had a number of specialist areas such as network engineering, broadcast engineering, and satellite engineering. Given the rapid broadcasting shift towards more cloud-based workflows, there is now the need to understand not only these areas but the medium of delivery. In the case of IP, we find that the lack of understanding around the specific requirements of IP for broadcast causes challenges.
If there is a requirement to set up satellite feeds, you use a satellite engineer and not a network engineer. The satellite engineer has the required skill set for this type of deployment and so naturally is the right person for the job. The same applies to setting up IP feeds, you need an IP specialist to support these workflows, rather than an engineer whose expertise lies in a different area of broadcast. But again, the IP specialist working on the project must have broadcast experience, a network engineer does not have the right understanding for broadcast-grade IP.
Mind the gap
Content owners are under immense pressure to keep delivering more feeds, more efficiently to broadcasters and affiliates. They need to do this in a way that minimises cost yet does not compromise standards. This is never more of a concern than during a live event, as fans demand both high-quality and uninterrupted viewing. Live sporting events can create the ‘perfect storm’ scenario. Infrastructure often needs to be set up quickly to accommodate last minute rights acquisitions, and mistakes can seriously disrupt a broadcast.
It is clear that IP has the potential to solve a lot of the challenges that the industry is currently facing, as well as help to future-proof delivery workflows. But to do this, the difference in infrastructure needs to be understood. Typically, content owners look at the transmission mechanism in the first instance, without considering the payload requirements or the hardware processing capabilities. This creates a problem from the outset, and one that is difficult to fix retrospectively.
There is a pretty wide gap between where the industry is now, and where we need to be in terms of broadcast IP understanding. It is time for IP engineering to be recognised as being a separate and additional area of specialism, rather than a bolt-on to existing roles. A crossover between, network engineering, broadcast engineering, with a pinch of cloud on top, fits the bill. Using experienced IP content delivery providers that meet broadcast-grade standards, will help close the knowledge gap between different specialisms. By acting as a bridge to troubleshoot challenges and find effective solutions, IP specialists can connect all the different components of the new media landscape together.
