We use cookies on our website to improve your online experience. By your continued use of the site, you consent to the use of these cookies. To learn more, please read Net Insight’s Statement on Cookies and Net Insight’s Statement on Privacy. Read More

Broadcast in the cloud demands a new kind of connectivity

It’s time for Open Broadcast Networking

The new wave of broadcast networking

Reliable Internet contribution & distribution has quickly disrupted the broadcast networking landscape, both commercially in terms of price and performance, as well as technically by proving itself from a reliability perspective.

As Internet streaming technology is grabbing an increasing share of the network spend, the segment is becoming more fragmented as new vendors enter the space with dozens if not hundreds of different implementation flavors on the market, all promising to solve the same thing. To counter this increasingly fragmented picture, groups such as the SRT Alliance, VSFs RIST/TR-06, and even some vendors are leading the way for standardized ways of transporting professional media content over the Internet.

While these open alternatives technically provide a new common ground, there are still significant commercial benefits for broadcasters to support different ecosystems. Both to maximize their content reach, but also to avoid lock-in effects. For broadcasters and operators, this means working with multiple different implementations to support a wider variety of use cases and infrastructure providers, meaning the promised holy grail of one single standardized solution is not realized.

Therefore, vendors and broadcaster need to embrace a wider adoption of implementations to fully reap the benefits of both different Internet transport ecosystems, as well as different public cloud providers.

We need #OpenBroadcastNetworking.

But what is Open Broadcast Networking?

While Internet transmission was exclusively a proprietary technology and still remains so in many cases, there have been several open alternatives emerging in the past few years. While this is natural and welcome evolution, the challenge is just there in the wording – several. So, while the protocol itself is open, you still need to pick a horse and bet on it.

Let’s review what has been happening during the last few years.

The SRT Alliance was formed providing a free, open source alternative for reliable transmission

While this is certainly not a standard from an industry forum, SRT has quickly become a de-facto standard in many organizations. With its 150+ strong member base, including backing from the likes of ESPN, Comcast, and the EBU, SRT has experienced a massive uptake in adoption since its launch just two years ago. With Microsoft Azure recently announcing support for SRT as an ingest protocol, it is now also the default protocol to get your content into the Azure cloud.

RIST/TR-06 was released

With the release of the first technical recommendation for Reliable Internet Streaming Transport (RIST), VSF has made the first move in what is promised to be a series of increments for various applications for reliable Internet streaming. If there’s one thing we can be absolutely sure of, it’s that this will start immersing itself into RFP processes quickly, with customer adoption to follow shortly after.

Similar to SRT, Zixi is considered a de-factor standard by many in the broadcast world. Having been early on out the market, Zixi is generally considered to have one of the most robust and field-proven implementations out there. With Zixi recently being announced as one of the official ingest partners for AWS Elemental, you can expect that support for the Zixi ecosystem could be equally important as SRT and RIST going forward.

The shift to cloud demands openness

So why is all this relevant now? Traditionally, video services have been exchanged on clear demarcation points at the edge of the network, most often to support content exchange between different operators or rights holders. These demarcation points, typically based on standardized (and often physical) interfaces such as SDI, ASI or IP, provides a standardized handover format both to external organizations and internal within the organization itself.

As new use cases and workflows continuously emerge, including cloud-based playout and production services, getting content to and from cloud services providers is becoming the essential objective of network transmission. WAN connections are no longer just bookended solutions that move content between two physical locations where both end-points are provided by the same vendor, instead, these WAN connections have evolved to start or terminate from a fixed or mobile location to or from a public or private cloud environment. This means that we are interconnecting two end-points that are likely owned and operated by different organizations. Consequently, the technology will most likely be provided by different vendors and based on different protocols. This reality has already arrived, and we are now facing interoperability requirements on the WAN interface whereas previously such interoperability requirements were confined to SDI, ASI or IP client interfaces.

To optimally support the new reality and emerging use cases, the technology used to protect content over the Internet needs to evolve from proprietary point-to-point delivery to open and interoperable delivery. This approach is already required to support use cases where encoders need to forward or receive content directly to or from cloud providers, in addition to direct cloud-to-cloud content exchange. Similarly, broadcasters need this future-proof ability for direct content exchange with third parties. Currently, such broadcast solutions are dual-box based with format handover on a physical SDI, ASI or IP connection. By leveraging the mature Internet transport market and an increasing number of available technology options, we can build operations-optimized solutions that both support multiple technologies and spans across vendors and cloud providers.

What we need is a new generation of Internet media transport, what we need is #OpenBroadcastNetworking

But there is an actual standard now, can’t we just wait for mainstream adoption?

So why wouldn’t we just bet on RIST (it is an industry standard after all) as the tech of choice and be done with it? We can, but considering the existing footprint already claimed by others, RIST is not likely to replace all of them any time soon. Therefore, supporting just one open protocol simply won’t be enough, thereby making bridging multiple protocols seamlessly a fundamental requirement. This is required to be able to move content from A to B across multiple operational domains, also when that happens to traverse technology domains or vendor ecosystems. Granted, while just bridging multiple protocols in itself is certainly not rocket science, achieving this while also preserving all the properties we today associate with reliable broadcast quality Internet transport is a different thing. These aspects, such as end-to-end management, security and resilience will all be key to this equation. Fundamental properties of Internet transport which all remain important but will be significantly harder to realize in cross-technology domains involving multiple protocols and vendor implementations.

Where is my silver bullet?

So, there you have it. It may have been “One ring to rule them all” for Mr. Frodo, but it certainly doesn’t seem to be for anyone in the broadcast world. So, given that this is what it is, what conclusions can we draw from it?

For us at Net Insight, the most important take away is that while the industry is moving from proprietary to open, for the foreseeable future we will still have a fragmented technology landscape with multiple retransmission protocols growing their footprint in the market. With SRT and RIST now being the top two open contenders, vendor eco-systems such as Zixi in fixed line and LiveU, TVU Networks within the news gathering space all have equally impressive footprints.

In addition, and perhaps more importantly, with the major cloud providers today picking different protocols to ingest content into the media suites, there is simply no one-size-fits-all solution.

Our conclusion is that there is simply no silver bullet. Sure, you can pick a vendor and cloud provider and go with that, but then you’re locked in – again. And what happens when you want to switch? Or exchange content with someone else?

We believe that the answers to the previous question lead to the same conclusion and deployment strategy. Open and interoperable media transport is and will remain the long-term answer. It won’t be enough to just support one protocol. It likely won’t even be enough to support several. The answer lies in adopting several parallel protocols while taking additional steps to retain the properties we have come accustomed to from Internet transport providers, but across protocols, implementations and domains.

For studios and dedicated WAN infrastructures, we are successfully converging on SMPTE ST 2110 as the destination. Similarly, to support cloud ingest and content exchange over unreliable and noisy networks we need to support a cohesive suite of Internet transport technologies. The silver bullet is yet to come.