If Interoperability Is Worth Doing, it Is Worth Doing Well
One of the downsides of cutting-edge innovation is that it can lead to technology being developed in silos. The development of next-generation solutions and services require a significant amount of investment, both in terms of time and money. So, it's only natural that companies would want to secure their intellectual property and recoup that initial investment. One way they do this is by tying new developments into restrictive frameworks. However, this can create a cycle of interoperability problems. This is something that we are currently seeing with IP transport protocols, and without agnostic infrastructure, IP delivery becomes less accessible for the industry as a whole.
Forward-thinking interoperable solutions bring with them a set of capabilities that are more than the sum of their parts. They enable new customers to adapt to changing developments and take advantage of new innovations in IP technology. This means media companies and broadcasters can then better respond to customer challenges, and work in an agile and flexible way. But there are important considerations and requirements to factor in.
An industry at a crossroads
It is well documented that Covid has hugely accelerated the broadcast industry’s adoption of cloud-based technology. Despite having used cloud-based working models for at least some workflows during the pandemic, there is still a reluctance among broadcasters to diverge from traditional processes and methods. Where there is an established culture of always doing things a certain way, it takes a leap of faith, and time, to change mindsets and do things differently.
There is also some confusion around what constitutes ‘broadcast-grade’ IP which needs to be resolved. Broadcasters being asked whether or not they support SRT for instance, often leads to them looking at a datasheet of a piece of equipment they own. If it says it supports SRT then it is selected. But interoperability and standards matter, if a broadcaster is delivering an IP feed it’s not a just case of using any encoder. Likewise broadcasters also can’t simply assume compatibility with the decoders at the other end. Broadcasters need to remember that the encode, transport type and decode components are entirely independent of each other. For example if an encoder can send a Zixi feed, it doesn’t mean it can create a valid TS. If a decoder supports SRT it doesn’t mean it can process the audio being presented.
The nature of the beast
Transporting content is a complex engineered process. It is a series of moving parts and needs to be engineered to ensure that the moving parts are all doing the right thing. Getting content from point A to point B when both points are not guaranteed to be speaking the same language is a challenge, but it is not insurmountable.
So, is it a question of just making sure encoders and decoders are interoperable? Unfortunately not – what we then see is a situation where vendors are marketing tools as compatible with different protocols but in doing this, there is no guarantee of standards and broadcast grade quality being met. Despite vendors marketing these tools, the difference in transport protocols continues to cause problems for broadcasters, and IP delivery is still not viewed as easily accessible by the industry. So where does the answer to this challenge lie?
Treat the cause, not the symptoms
Media companies generally don’t want to get bogged down with the complex engineering intricacies of interoperability. What they want to know is, is the audio and video there in its entirety and is it in sync?
There are lots of protocols out there for transporting content over IP. However, they don’t always communicate well with each other. Vendors are building encoders and decoders to incorporate certain transport protocols but in doing this, they are treating the symptoms rather than cause of the problem. By combining encoding/decoding and transport into one function, there is a risk of confusing the whole workflow.
In practice, let’s say an encoder that is SRT compatible is able to send content to a decoder that is also SRT compatible, yes it can receive the content but, it may still not be able to actually process the unwrapped transport stream. Encoding and transport are 2 separate functions and should be treated as such. It’s not as simple as just ensuring that both encoder and decoder can speak the same language.
There are many components to a video feed but two key factors to consider are:
- The features and functions of the encoder/decoder. Can it process a CBR feed? Can it process multiple audio channels, how many and which codecs? Can it process SCTE triggers, can it encode at 4:2:2 10 bit, does it produce a valid TS?
- The output of the encoder. Does it transmit UDP/RTP only, can it send Zixi or SRT or RIST or any other suitable protocol.
A different approach is needed
Another factor is that there is often a complete separation between the approach taken by commercial broadcast and technical teams when it comes to IP delivery. While technical teams are seeing clear benefits of IP delivery and adapting to its requirements, commercial teams are still reluctant to embrace change and can appear to be stuck in the mud when it comes to transitioning to IP. Using IP for transport is sometimes outside of a commercial comfort zone, despite significant financial benefits, but that’s where the industry has a responsibility to make the technical workflows clear. If the same question is put to a technical team, then they are much more open to IP delivery and have measures in place to enable it to happen. There is an internal dichotomy in place.
Broadcasters need pre-determined methods of dealing with and handling content, rather than last minute panics about transport method and ability of destination takers to receive IP content. The last-minute nature of some content is inevitable, such as rights negotiations for live sports broadcasting that runs down to the wire. However, broadcasters need to invest more in their ability to send and receive IP so that a framework is in place to spin-up infrastructure time and time again. There also needs to be a much more joined up approach between commercial broadcast and technical teams, so that knowledge and understanding is shared.
A way forward
While roll out of new technology can sometimes be restricted, thankfully, innovation doesn’t exist in a vacuum. This is evident in the emergence and gradual adoption of IP delivery across the broadcast industry. Its development was very much a combination of ideas across the sector, with companies innovating and developing, based on the work of both partners and competitors. Likewise, the industry has the potential to make IP accessible so that more media and broadcast companies can benefit from the opportunities it brings.
If interoperability is possible, which we know it is, then it is worth doing properly. Media companies don’t need to be tied into a restrictive framework, it is possible to be more adaptable and agile so that they are better able to deal with last minute complications.
New innovations, such as on demand transcoding for live events – taking in a feed in one format and sending it out in whatever format, resolution, frame rate and specified IP protocol is needed – are game changers. This makes much more sense from a technical perspective than sourcing new equipment that is pre-enabled to be compatible with specific protocols. It also decouples the source feed from the destinations which allows last minute additions to the broadcast workflow and offers much needed flexibility in the workflow, so IP is better able to meet the needs of broadcasters.
By investing in better ways to handle and manage content delivery by IP, organisations can offer greater compatibility instead of locking customers into a proprietary and potentially limiting approach. In the interim, those with IP expertise have a responsibility to ensure interoperability is at the core of decisions that broadcasters are making. However, it is also the responsibility of broadcasters to either invest in IP standards training for their engineering teams, or make sure they are supporting engineers with more of a managed service approach. The technology already exists to deliver low-latency, broadcast-grade content by IP, and now the systems around that technology are evolving to take it to the next level.
[Editor's note: This is a contributed article from Cerberus Tech. Streaming Media accepts vendor bylines based solely on their value to our readers.]
Companies and Suppliers Mentioned