Making Cloud-Based Remote Editing an Operational Reality

In this case study we're going to talk a little bit about the backend of everything with regards to the streaming world. At TMT Insights we've spent a lot of time focusing in many of these conversations about the experiences, both from a consumer perspective and looking at how people monetize merchandise. But a lot of this begins behind the scenes with the digital supply chain aspect of it, and we've been very fortunate to have a long-term relationship with the crew at A+E in terms of transforming their supply chain. And so we're going to talk a little bit about what we've been going through in terms of remote editing and some of the transformation processes there, as well as our roadmap perspective and where we see things heading across the industry with a number of our clients and the work that we're doing together.

A+E's Transformation Journey

Like many media companies, at A+E we've been through a huge transformation, especially over the last five years or so where we've gone from focusing on those linear cable channels to being a very strong multiplatform company where we were distributing content on a variety of different streaming outlets, moving content into many different applications and services. And while we have some of our own websites and apps, some of our own platforms, we've made an intentional choice over the last few years to not just limit our content, to not just pull our content back to only our platforms, but instead to work with everybody else, which means that we're building integrations and supply chains and tools to get content from our network platforms to many different streaming platforms domestically and around the globe.

When I started working at A+E about five years ago, we started talking about what we wanted to accomplish. We knew that we were ready to get started with a new approach for a lot of our media infrastructure and a lot of our media processing. I had a unique opportunity because I was starting a new department there. So I didn't have a whole lot of legacy equipment or legacy workflows or systems to help maintain. I could move around and get to know people around the organization and get familiar with what people liked, what people didn't like, and what people saw as the opportunities coming up for media processing at the company and some of the challenges.

These became the foundation for what we decided to do next, and the recognition that everybody wanted more agility.

Everybody--especially business teams who are working with our content--was trying to make good strategic decisions about where our content goes, what platforms it's on, and what we're doing with it. People wanted to take advantage of new opportunities. People wanted to be on a new platform or take advantage of a hot topic in the news cycle or make a new type of content if it made sense for A+E. People wanted to get there very quickly. They wanted to be very agile about taking advantage of these opportunities.

The second theme that kept coming up from our media operations groups, our internal teams trying to get content everywhere it needs to go, is that everybody was tired of sitting in a queue and waiting for things to process. They were very tired of sitting around waiting for content to restore out of an old LTO archive or waiting for these transcoders to go through and get content prepared and ready to go where it needed to.

We knew we wanted to work at a higher volume. We knew we wanted to scale up and be able to process lots of things, but that also meant being able to burst, because we didn't want to just maintain a giant infrastructure forever.

The third big theme that kept coming up was efficiency. The idea that so many of these workflows and so many of the systems and tools were built for those linear cable channels that showed at the beginning and the middle and now we're being asked to handle not just one output or six channels worth of linear outputs, but maybe hundreds of different outputs all around the globe. So everybody knew we were being asked for an exponential amount of growth in terms of the amount of content we were processing, but of course we're not being given an exponential growth in staff to help solve that problem and get everything through the pipeline quicker.

So we knew we needed to be more efficient and we knew we needed to be more automated and handle that exponential growth that was already starting five years ago, but we could see more and more coming our way. So for each of these things, we came up with a guiding principle to help enable that for agility. We focused on building targeted tools that were loosely coupled with each other, tools that would be easy to update and change and make work together over time. We didn't want to build a giant monolith, like one big content management system or one big MAM or DAM system that would try to solve all our problems. We wanted a series of tools that solved specific problems well and made sure they talked well to each other.

For the elasticity bit, we knew we needed to build in the cloud. There's no other way to get the scale that we wanted where we're processing thousands of things one day and not very much the next. We knew that cloud infrastructure and the ability to flex and scale based on volume and needs was a part of our future. We had to get stuff out of our aging infrastructure in our offices and into the cloud.

We thought about efficiency and we started to think about a lot of ideas not just for automation but for lean manufacturing. A lot of these ideas that have been very popular for supply chains and processing in the manufacturing world, where you're making refrigerators and cars and microwaves. The idea of manufacturing and supply chain is very simple at its core. It means taking raw materials in, applying a process to them that gives them value, and then in the end having an output, a finished good or something that people want and you sell that to them.

Media as a Supply Chain

So we wanted to take those principles--those very simple ideas of having inputs, applying processes, and getting outputs--and move that to our media processing world, which is where we got into this concept of media as a supply chain. And so we took the processing that different teams were doing, and we started to think of it together as one unified supply chain, as one unified set of steps where we're getting content in. And for these use cases, most of the time the content we're getting in is finished programs and movies from the suppliers that we've asked to make it for us. Then need to do some work to it often we need to make many different versions of it: a version for linear premieres on cable, and then maybe a version with an extra commercial break for rerun versions with different content added in for international use or taken out different translations.

Many different versions get created in that middle "during" section. And then the outputs--that's where we're getting those versions. We've made all these different episodes of television, all their different versions distributed to everybody in the formats they need with the metadata they need. So it's in all the streaming services and available to everybody it should be available to. So we started to think of our supply chain this way of in during and out, and we started a lot focusing on inputs and thinking about how to get our content into the cloud when we started building up our supply chain tools. And then we had some great opportunities on outputs where we had some large streaming deals we were trying to make happen, and we were able to automate getting some content out to some major platforms as part of launches. But for a little while there, we would have content coming in the cloud in our new tools. It would come down to the ground and we would edit it and make these new versions and edit suites and with video editing tools that people would be familiar with, and then it would come back up into the cloud to get distributed.

A Supply Chain Approach for Video Editing

About a year ago, we set out to say, "Great, we want to make this supply chain totally cloud native from end to end. We want that middle part, that editing part to come up into the cloud as well. And we want to think about it in a new way for this context of editing, for supply chain use cases, editing for reversioning, and getting things where they need to go." And if you're into video editing, you might think of it as more of a creative process. I started as an editor and I certainly think of it that way.

You think about telling a story, and even if you're working with a finished show or movie and trying to make different versions of it, you're still thinking about the story, thinking about how to tie things together, how to make changes to it in order to make it an effective narrative and effective story that's going to work well for its use case.

That's a very creative process, but at the same time, there's a lot of stuff in that process that isn't as creative. And so our goal was to take a step back and think about how this video editing worked for supply chain and take an approach that would make it more friendly for people who are doing that work every day. So, relying on those key principles we came up with, number one, we wanted it to be agile because we knew we were going to have different requirements, different needs.

We wanted to incorporate different tools over time. We didn't just want to build a thing and then get into a capital cycle where five years from now we'll rebuild it and five years from now we'll rebuild it again. We wanted a process that could grow and change with us very easily, and we also wanted it to be elastic. We didn't want to be tied to a physical facility with a physical number of edit suites, and you could only schedule somebody to go in and sit in the dark room for the day with their video editing equipment. We wanted to be able to do a lot of content processing when we had a big deal to do and scale back down and not pay for all of that extra infrastructure when we didn't.

Then, when it comes to efficiency, we wanted to automate as much as we could so that editors come in, have everything ready for them, in the right place, ready to go, and the editor applies their work, does their changes, and puts it back to the system to do everything else, to get things as much as possible that don't need to be done by the editor out of the editor's hands and into the system.

The Solution

So, to solve those problems and to build a new thing, we reached out to our partners at TMT Insights. We engaged with them to help build some of these new automated supply chains and rely on a tool to tie it all together called Polaris, which Andy will talk about in more detail, and also explain how we used it to tie together the operation. And of course, we're working with our amazing in-house engineering team to build these automations, make things move, and be able to tie it into all of our other systems internally so that everything gets where it needs to go based on our business needs.

Tackling the Middle of the Chain

So this is how it came together for us building this new cloud-based video editing environment to enable these high-volume workflows. We have three key tools at play that we're relying on.

First, sdvi | rally is our workflow engine, our orchestration engine. This is a SaaS tool running in the cloud that we've been using for our supply chain workflow since we got started, and it allows us to automate a lot of these workflows, transcode things, scale up and scale down video transcoders and video processing when we need them, and that way we have them when we need them and we're not paying for them when we don't.

arch platform became another SaaS partner we found to help build our video editing environment in the cloud, which looks and feels like a video editing environment anywhere. It's a workstation with Windows installed and Adobe Premiere Pro and a bunch of creative tools and some storage mounted. You log in, you do your work and you log out, and I'll talk a little bit more about that in a moment.

And then Polaris is, for us, the system that ties it together. It takes what we call our operations management system, all of these things happening in the operation--the automation, the workflows, assigning tasks, tracking status--and it puts it all together under one pane of glass and one interface so everybody knows what's happening and is able to interact with this complicated automated system.

Then of course, our A+E engineering teams are not only writing a lot of the automation code, but helping tie this all together with our internal systems. So at a high level, here's a quick diagram of how this has all been coming together for us.

click the image to see it at full size

It starts with our users who are working. Most of the people working in our A+E environment on video editing tend to be working at home--we're a very remote-friendly organization. They have their laptop at home, they use a web browser, they log into the arch platform, and the arch platform helps connect them to their virtual machine. They see a list of virtual machines that are open and available. They click on one, it logs them in, and that virtual machine is running in AWS running in the cloud, has Adobe Premiere and all the creative tools installed they need, and it has their media ready to go. It's connected to some shared storage, which is connected to our workflow engine and automation and everything running the cloud.

When somebody places an order and says, I want to edit a piece of content, they do that in the Polaris order management system. It kicks off a workflow in the rally orchestration engine. That workflow makes the right content, gets it into a proxy, loads it up onto the shared storage, and links it into a panel in Adobe Premiere Pro.

If you're an editor, you log into Adobe Premiere and you have a list of tasks when you first log in that tell you the things that you've been asked to work on for the day, the different shows you've been asked to edit. You open it up, your timeline loads, and your media has been copied in automatically for you. Everything's there and ready to go. You go through and do your edit, and then you also need to fill out some metadata, take some markers from the timeline, and mark them in the metadata panel. That way we know all the information about this show, which audio track is which, where every segment starts and stops, where the credits are--all the information that's useful to us to help them automate the use cases downstream.

When you're done with your edit, you hit complete, and it actually then comes back up into the cloud and it renders back up here in the sdvi | rally cloud ecosystem in AWS. The Adobe Media Ecoder actually runs up in the cloud. So the editor worked on a proxy in their Adobe Premiere virtual machine, but when they hit submit, the timeline goes back up into the cloud and it renders off of the high-res media, and we make the new master so the editor doesn't have to watch paint dry and wait for a render to finish. They just move on to their next job and they keep going, and then the system goes through and automates the rest of that workflow.

The Power of Polaris

The problem statement that we tried to solve with Polaris is obviously not unique to A+E's challenges, but across the industry. There's a myriad of systems--SaaS, homegrown, old, antiquated on-prem environments--and many of those don't even have UIs that are designed for content operations teams. They may be engineering-esque focused UIs and may not tell the whole story. The whole point of Polaris is a single pane of glass that creates a nomenclature and visibility that also allows for that order management, task management, but reaches into all of those things.

It's not replacing any one of these things; it's bringing a semblance of order to all of it so that we can now enable all of that without people having to know all of the various systems in nth level of detail. The entire point was, how do you start to aggregate all of that information and make it digestible?

So whether you need to move assets over to an FSx storage array, or you need a notificatoin when it's ready for an editor to action, or you need to have communication between editors and producers when late assets arriving from production, it's the orchestration of all of those tasks. In the world of, "I sent an email, the thread of the email was one topic, and 17 messages later we're talking about something else, but the thread subject line never changed," there's no auditability to what's happening here. We've now consolidated all of that through one holistic view.

That's what enables all of that efficiency. So when it comes to the question of how do you get exponential growth without having exponential growth in cost and overhead, it can only be achieved by putting these things in. That's very much why we built it, and we've had a lot of success with A+E and others in putting that in place.

Bulk Distribution

This slide shows a picture of where that manifests itself when you start to look at the distribution of all of this content.

We've been talking about the singular, so to speak, in terms of all of the creative workflow of making those compliance edits and so on and so forth. But we've now realized a world of this concept of late binding, which has always been the dream, whether it was IMF or even non-IMF, but wanting to achieve it where you can send out a core video and then subsequently follow it up with subtitles, dubs, closed captions, or whatever it happens to be. This slide starts to show you how the change in the philosophy of approach that we've been putting in place together has started to bring that realization to life. So you've got unique episodes that you could see in these peaks shown there, but just during a simple window, within that peak period, there were over 300,000 components that were delivered that make up all of that stuff.

Everybody went from a world of wanting fully muxed assets that were ready to go to, wanting to make a Rubik's Cube of anything for everyone, and of course, all the time saying, "Let's add a logo. We have a new marketing logo, we want to do an international logo."

Nobody wants to go through the trouble of having to recreate the entire inventory every single time. So componentizing everything makes it possible for editors to not have to go and put assemblies together of all of that. And then everyone can just focus on the activities that they're doing that they're great at, and then get the machines to pick up the heavy lift of what's an arduous task is now coming through in full fruition. So that's very much how we've approached it.

Looking Ahead

That, of course, leads us to, where do we go from here?

We've got a bit of a combined roadmap of where we're headed. Obviously, we're continuing to roll out bulk distribution. That's very much the focus of the next several months: continuing to onboard all of the different endpoints that we can send to for all of those machinations. AI, clearly the flavor of the year--if anybody looked at Nvidia stock today, you would see it popping. So we're continuing to do R&D and tool testing. We're being very judicious about that. There's a lot of tools out there, but some may be fly-by-night and disappear very quickly, and some may be cool, but then you have a solution in search of a problem. And so we're trying to hone that in and focus our attention on things. We have ongoing operational enhancements. There should always be iterative improvement to everything you do.

Avails and metadata management is the next big challenge for all of this, because we have ordering, and the mechanism of people being able to go in and say, "I need these 500 or 1,000 titles." But what you want is the triggering of all the rights to generate all of that stuff systemically. And then having people, again, from an exception-processing perspective, because just the sheer amount of business growth dictates the fact that it can't just be down to people with spreadsheets. And then of course, putting the AI enhancements in after all the R&D is done, but focused around compliance, translation, assembly, all of those things. If I have to hear one more time, somebody talk about replacing a Coke can with a Pepsi can in a video, that's cool. I don't know what the business use for that is exactly, but if somebody needs one, there are plenty of things out there that'll do it. But we need to find something that allows all of that scalability to come in place.

Finally, all of this is for naught if we can't integrate with financial systems, because there's royalty reporting, which people will focus a lot of attention on. But whether you're doing things like billing or split billing between parties and stuff like that, we tend to all talk about the costs of this being the AWS or Google costs. For example, how much did it cost for the transcode? That's a hard cost, but how much did it cost to master? How much did it cost to QC? Did you have to localize? Did you go to a third party? What's the actual cost for a sales team? What's the actual cost of manufacturing when you take into account everything that's involved? And does a deal actually make sense to do if they can forecast that on the fly before they ever actually consummate a deal?

So that the rub between sales operations and the sales forces out there can actually know that before manufacturing ever begins, it fundamentally changes how people are doing deals and executing on them. So it is a fairly large transformation that we're seeing, not just obviously at A+E, but across the industry that are all looking at these things holistically.