The implementation of IP can solve numerous broadcast industry challenges, but to function optimally it must be understood and used correctly. Not all IP is created equal and context is everything when it comes to transporting broadcast-grade feeds. Understanding the ‘why’ and the ‘how’ of IP, means broadcasters and content owners will be in a much better position to maintain high standards in a cloud environment.
This blog is the first of a two-part series that sets the standard for IP contribution and distribution, without compromise.
Traditional Content Delivery
The traditional method for transporting broadcast feeds is set out in a very clear, iterated, and well-defined workflow. Content is fed into high-end encoders that are meticulous on standards. The feed goes in as SDI and comes out as ASI, for multiplexing and transmission.
For live events, equipment is sent to a location in OB production trucks, and it mirrors the equipment back at HQ. This means that all of the broadcast infrastructure adheres to the same standards for quality, bitrate, chromaticity, audio bitrate, and packet timing. By adhering to consistent standards, feeds can be seamlessly received, processed, and transcoded.
The Roots of IP
While the broadcast industry maintained traditional methods for transporting content, there was a quiet revolution happening online. IP delivery was initially created and designed for transport to online platforms. Feeds were transmitted using RTMP encoders, and the process placed less importance on details like packet timings. RTMP wasn’t a broadcast-grade feed and was never intended to be used for broadcast content at that stage.
Then, the two separate worlds of broadcast-grade transmission and IP collided as IP protocols for broadcast, such as Zixi, RIST and SRT were created. These protocols enabled encoders to configure the package of information required for a broadcast transmission and wrap it in a transport protocol for delivery. But this has presented a challenge.
The sending and receiving hardware may appear compatible as they support the same transmission protocol being used (but often this is not even the case), however the issue is not the wrapping, but making sure what’s on the inside meets the required standards.
The Right Ingredients
As more and more encoding and decoding solutions now claim to support these protocols, there is a misconception that what they produce is always broadcast grade. This is not necessarily true as many OTT encoders now support SRT or Zixi but cannot, for example, support MPEG 1 Layer II audio, and it is also not likely to carry more than one audio pair.
Packet timing is another element required for dynamic, live broadcast workflows, and without it receiving decoders often cannot display the video.
In this case you really can’t judge a book by its cover. The protocol title might be the same, but inside you could be missing whole chapters of information. It is a common misconception that all these feeds are broadcast quality. This is incorrect because the transport protocol does not define or describe the payload.
Just because the hardware supports Zixi for example, it doesn’t mean that the transmissions or the actual video package is compatible with receivers or the downstream workflows.
Ensuring Compatibility
The transport mechanism and the payload are two separate factors, each with a different set of requirements. It is critical to understand that while encoders and decoders may speak the same language, the message might still be misunderstood. Effective implementation of IP in a broadcast environment requires an understanding of a well-defined set of standards. And when it comes to designing broadcast infrastructure, different skill sets are needed.
A whole new set of criteria will be required for cloud-based content delivery when compared to a traditional broadcast engineering framework. To understand more, read our follow-up blog – Defining Broadcast-Grade IP. Or get in touch with our team if you have specific questions on your own workflow.
