SVG Sit-Down: AWS’s David Griggs Explains the Importance of AWS CDI for Live Production

Cloud-based network tech could be a game-changer for live-video workflows

Last month, AWS unveiled the AWS Cloud Digital Interface (AWS CDI), a new network technology that allows Independent Software Vendors (ISVs) and AWS Partners to build live-video applications that can connect products and services within the AWS Cloud.

Many in the broadcast and M&E industry see CDI as an impending game-changer for live production, potentially opening up the opportunity for fully cloud-based workflows using uncompressed live video. Traditionally, these types of workflows have been deployed on-premises using SDI or dedicated-network IP infrastructure. However, CDI would allow them to take advantage of the agility and scalability of the cloud. With CDI, broadcasters can deploy live-video solutions — such as TV-channel playout, motion-graphic insertion, multiviewer applications, live-video production switching, video-frame-rate and color-space conversion, forensic watermarking, and video-encoding/decoding — in the cloud.

SVG sat down with David Griggs, senior product manager, AWS Media Series, to discuss what CDI means for the sports-production industry, how his company’s AVM (audio, video, and metadata) schema allows interoperability, what CDI means for SMPTE ST 2110 and other broadcast IP standards, how CDI could affect broadcaster and ISV business models, and what the future holds for CDI.

Also, if you’d like to learn more, register now for the SVG Technology in Action Webinar Series: “Introducing the AWS Cloud Digital Interface Presented By SOUTHWORKS” on Oct. 20 at 2 p.m. ET. More info here.

AWS’s David Griggs: “I would love to see is a high-tier sports event produced entirely on virtualized instances, running in the cloud with multivendor support and a production crew sitting at home.”

Why does AWS believe CDI will have such a major impact on the broadcast and M&E market?
There’s a segment of broadcast workflows — of which sports production is one — that today are anchored on-prem because of their dependence on things like timing sensitivity and uncompressed connectivity and, therefore, are not well-suited for migration to the cloud. We wanted to address that problem.

I see CDI as a technology stack that provides this high-capacity, high-bandwidth, reliable connectivity so that vendors across the production, broadcast, and M&E space can start to think about how their products and services can transition to cloud workflows — whether that’s a lift-and-shift or a reimagining.

How do you see CDI changing the way broadcasters and production companies operate in the future?
Broadcasters and production companies are excited about the idea of a cost model linked to utilization. When a production company like NEP purchases [equipment] today, they will basically provision for the biggest possible event they’re going to do. That causes headaches because they are spending all this time trying to figure out how get that truck or production facility as much work as possible so that they can amortize it from a capex perspective. With a remote-production model and the centralized-production model, we’ve definitely seen increased utilization, but it’s still a problem because you still have a utilization burden.

But, if you look at the way AWS has positioned its business over the years, it’s all about agile, scalable computing and a cost model that grows or shrinks based on the agility and utilization. If we could unlock that capability for these high-bandwidth, uncompressed–live-video workflows, we would completely transform that model. From a broadcast or production company’s perspective, that’s amazing because suddenly they are paying just for what they’re using as opposed to a utilization headache.

And how do you see CDI changing the way vendors and ISVs operate?
I think ISVs are also excited about [CDI] because this means a new opportunity with a new market and new revenues. It’s not just about converting their existing customer base to cloud. I think, if CDI does what I hope it will do, it will unlock a whole new business in production.

Today, there’s so much content out there, sports included, that isn’t produced because there’s a barrier to entry that is usually related to cost. CDI will allow our ISVs and technology partners to introduce more cost-sensitive, affordable production capability in cloud workflows, which will suddenly open up a whole new tier of content that isn’t produced today [but] could be in the future.

What is the process for ISVs to begin developing offerings based on CDI?
The first thing we’ve done with the CDI technology is, rather than productizing and commercializing a whole bunch of technology, we launched an SDK [software-development kit]. That gives ISV’s access to the CDI technology stack and [offers] interoperability. By launching that SDK and making it available at no cost — which I’m really thrilled about because that was essential to the success — we’ve created a very clear and frictionless way for ISVs to get on board with CDI.

First and foremost, go to the GitHub repository and download the SDK, and there’s a whole swath of documentation available online. Of course, it’s a fully supported AWS product, and we will continue to nurture it and make sure that the companies are getting the best out of the product.

I would also encourage experimentation. We’ve engineered the SDK so that, if you’re a software engineer that’s worked with ST 2110, ST 2022-6, or SDI in the past, we’ve created an interface that has borrowed heavily from those standards. If you’re walking in with the experience of an SDI engineer, it should be a familiar space for you with videocentric terminology.

How is AWS looking to work with the broadcast industry to integrate CDI more seamlessly into existing workflows and standards?
It’s important to understand that there are really two separate parts to CDI. First, there’s the technology stack, which is proprietary and allows us to move the [data] around reliably and quickly at data rates that are equivalent to on-prem standards like SDI. We can move a frame of video in 8-12 ms, which is well within SDI specs. To do that, we had to use a bunch of proprietary technology that knows how to survive and thrive in our multi-tenant network; ST 2110 just doesn’t fly in those kinds of environments.

Separate from the technology stack of CDI is the audio video metadata (AVM) layer, which is not proprietary. It is designed to be an open standard and is in the SDK as a separate schema. We want to promote that through industry bodies and get buy-in across the board from multiple vendors so that we end up with an interoperability standard.

I think SDI on-prem is actually a good analogy here. There are two parts to SDI: there is the physical cable that represents the actual technology, and there is the byte-packing, which is the way the data actually moves from one device to the other. If you buy a graphics machine or a switcher, you just connect them via SDI, and you know it is going to work. There’s no debate there. We want CDI to have that same interoperability quality in the cloud.

By detaching the byte-packing schema and offering it [to the public], we are looking to industry bodies to ultimately build a consensus around byte-packing in the cloud, and that will be reimplemented in the technology stack. We can have an interoperability standard that takes away the friction and the concern around how to extend your existing broadcast infrastructure into an [Amazon] EC2 environment using CDI. The two will work together just like SDI does on-prem.

Does this open up potential opportunities for fully uncompressed workflows between multiple locations?
The short answer is yes. This is the first step in that direction, and there’s enough value in CDI to give ISVs the ability to start thinking about it seriously. Previously, in the cloud, there was no way to move video around between instances of EC2 that would support a live-production workflow: eventually, you hit this CPU or processing limits of that instance.

But CDI gives you the ability to build an instance that can expand or shrink based on the needs of the job. I think that is transformative and will force both ISVs and broadcasters to take a serious look at this because it gives them the ability to start thinking about fully remote cloud production. And I think the industry is ready for that.

How do you see CDI impacting the remote-production model that has expanded significantly in sports production recently?
Rolling up these multimillion-dollar trucks to venues and paying for a production crew to fly out to each event is an expensive model. But I think broadcasters are ready to have crews stay at home, use bandwidth connectivity to bring iso camera feeds back to a centralized location, and produce centrally. And I think CDI is the piece of technology that suddenly makes it feasible to migrate all of that to a fully virtualized environment, where essentially you just spin up production resources as and when you need them and shut them down when you don’t. That shifts it from a capex to an opex model, which is I think really important as well.

What does CDI mean for established IP broadcast standards like SMPTE ST 2110? What cues did you take from these standards when building CDI?
I get asked a lot, “We already have an uncompressed standard in 2110, so why something new?” ST 2110 is a perfectly good standard, and I’m personally supportive of it.

But there’s one flaw: it is designed to work on purpose-built video IP infrastructure that you maintain deliberately and explicitly as a video network. The AWS cloud is the total opposite: a vast amount of traffic that’s not necessarily video-related is flowing around our network, and it’s multi-tenant. We needed to build a technology that would thrive in the AWS cloud, but we didn’t want to just throw away all of the great work that went into 2110. So, [for] the CDI spec, we have borrowed heavily from 2110 and wherever possible have mirrored the 2110 specs.

You will see the ST 2110-20, -30, and -40 variants — the video, audio, and metadata layers of 2110 — within CDI. We’ve been very careful to not completely reinvent the wheel. Yes, we’ve changed the way the bytes move around, because unprotected RTP just doesn’t work on a multi-tenant–network like AWS, but we’ve been very careful to make sure that we present that technology to the software developers and our customers so that it matches the 2110 standard wherever we could. I think it’s a healthy combination of a technology that has been built to thrive in a multi-tenant network but with a familiar interface for software developers based on 2110.

How does CDI interact with ST 2110 and other baseband or IP broadcast standards typically used in on-premises environments?
What we haven’t solved with CDI and we’re working on today is the bridge between an uncompressed on-prem environment and an uncompressed cloud environment, because, clearly, you’re not going to send an uncompressed video all the way into the cloud. And, whilst I can’t talk about specifics, we’re very cognizant of that. We want to make sure that CDI expands to have an answer for that problem. There is a vision of the future here where you can just totally and seamlessly connect your 2110 environment with a CDI environment. We definitely are aware of that, but we can’t talk about that publicly as of now.

What has been the feedback thus far from ISVs in the broadcast space?
It has been overwhelmingly positive. We didn’t just launch this on them; we had a beta program for some time. This is a whole untapped market that they didn’t have access to prior to CDI. Of course, the pivot is bigger for some [companies] than for others. Some probably have a clear vision where you can see how your products would just translate. But, for [those that] have decades of investment in their [physical] video technology, the pivot will definitely be bigger. But I would say everybody we’ve spoken to at least recognizes the potential.

This is not just a drop-in-and-run situation for us. We’re going to continue to support our ISVs and nurture those relationships so that, ultimately, we can build products and services together that broadcasters are going to use for live production.

How do you foresee the CDI ecosystem evolving in the next 12 months?
First and foremost, I’d like to see ratification, buy-in, and improvement of the AVM layer. That’s critical to me because, if we don’t have interoperability across vendors, we’re going to create high-performing processing islands, and none of them can talk to each other. We need to make sure that everyone has agreed that the AVM layer in CDI is broadly accepted and adopted by our technical partners and ISVs. Once we all agree on that, we can all talk to each other. That should lead to a really healthy environment where ISVs can start to migrate and build new products in the cloud based on their existing core competencies. If you’re an EVS or a Vizrt, what does replay or graphics look like in the cloud?

The second thing I would love to see is a high-ranking, high-tier sports event produced entirely on virtualized instances, running in the cloud with multivendor support and a production crew sitting at home. I think that is now an achievable goal. It might take all of those 12 months, but I don’t think it’s as far away as it might seem. And I think CDI has unblocked that barrier to entry that was there previously.

The AWS CDI SDK can be downloaded here. If you’d like to learn more, register now for the SVG Technology in Action Webinar Series: “Introducing the AWS Cloud Digital Interface Presented By SOUTHWORKS” on Oct. 20 at 2 p.m. ET. More info here.

This interview has been edited for length and clarity.

Password must contain the following:

A lowercase letter

A capital (uppercase) letter

A number

Minimum 8 characters

;
SVGLogoHR_NOTAG-200

The Latest in Sports Video Production & Technology
in Your Inbox for FREE

Daily Email Newsletters Monday - Friday