December 27, 2019
By Philip Harrison Solution Architect, Amazon Web Services
Featured Articles

How to Build Live Linear OTT Channels in the Cloud

Use Case

Let’s look at a real-life use case for one of our customers. 7 is a commercial broadcaster in Australia that has used this approach inside their apps. At the moment, they have a VOD catalog on the devices shown in Figure 7 (below): smart TVs, gaming consoles, web, and phones. They had two split architectures--one for live, one for VOD--so they were duplicating enoding, duplicating packaging. Basically the EPG guide shown in Figure 2 was driven out of an entirely different system.

re:Linear Live channel

Figure 7. How 7 created a re:Linear Live channel

But what they found was that they could actually reuse the VOD libraries and publish that via re:Linear and create a linear live stream. So they built a wrapper around it, consisting of an API call to create a channel, and an API call to select content to schedule.

They did so for a simple reason: It’s repeatable and it’s relatively cheap as I discussed earlier.

What does it mean that we now have an unlimited matrix of channel numbers-to-content mapping? We can go crazy with the types of live channels that exist.

The content team at 7 came up with small social media campaigns that basically said, “On Friday night it's going to be ladies’ night. We're going to put up a pop-up channel, a live stream that lasts only six to eight hours. And on that we’re going to promote what’s on, and we’re going to start a hashtag chain and everyone’s going to have this shared experience of watching this type of famed content, which is basically all content that they've scheduled themselves there” (Figure 8, below).

7plus re:Linear popup channel

Figure 8. A 7plus re:Linear pop-up channel

They took this approach for several reasons. First is that live audiences watch for longer sessions than VOD audiences, which means is that you can insert more ads. You can basically get more impressions, and get people to watch for multiple hours when it’s live rather than one-episode-at-a-time VOD.

Also, as mentioned earlier, it’s cheap. The only real cost of repurposing this content is generating text files. Generating text files is a lot less computationally intensive than re-encoding video assets over and over and over again. Channels will target key demographic audiences so they can start to address their audience in a much more discrete way.

So they can say, “We’re going to target females from the age of 18 to 40. These are the geographical areas that are most likely to watch it, so we can target that as well.” They can also give exposure to back-catalog programs to their targeted audience. For example, they have hundreds of hours of a soap opera that is basically only made because they sell it internationally, but the content exists inside their back catalog. As a result, no one might ever see it if they had to search through multiple pages of a VOD interface to find it. With this VOD-to-Live approach, 7plus can surface that as a live stream, and they can also monetize it through advertising and saying, “We have this show, it shows a lot of beaches, it has a lot of product placement opportunities, and a lot of addressable advertising.” They also have SCTE-type markers--not actual SCTE markers, but tags inside playlists--that enable them to do the server-side ad insertion as if the show were live.

Figure 9 (below) shows one of the homepages of the 7plus interface. Down at the bottom there, the live channel from this serverless playout is set right in the midst of the existing play out, which is basically a repeat of their traditional broadcast. So it really does look exactly like broadcast television to viewers. It’s just developed through an entirely different backend architecture.

a 7plus homepage

Figure 9. A 7plus homepage

This leads to the eventual state of hyper-personalization. Because the number of channels you can have is unlimited, theoretically, you could have a different channel number for every single one of your users. Imagine that a user ID is equivalent to a channel number. This means you could end up with a re:Linear channel per person that is essentially recommended VOD programming, recommended live (Figure 10, below).

individualized re:linear channel

Figure 10. An individualized, per-person re:Linear channel

We could also develop an Alexa skill that says, “Please play a live stream.” That small demo I did earlier would be executed automatically, and some content could be scheduled automatically in a live transmission starting from the point at which that person invoked that Alexa skill, and then they could watch five to seven hours of programming right then, right there.

Serverless Playout Architecture

The next two figures lay out a basic architecture diagram for serverless playout. Readers who have some familiarity with AWS should understand a bit of how it’s put together.

Figure 11 (below) shows media preparation (Figure 11, below). If you needed to re-encode your assets, you would begin by running it through MediaConvert. Then, on the output’s S3 bucket, a small Parse playlist Lambda function executes on any new files that are in there.

media preparation

Figure 11. Media preparation

But if you already had that VOD file defined, you could simply run the playlist files in the HLS files through this Parse playlists Lambda script and the result would be the same. So you don't necessarily need to re-encode files to add them to your scheduler. And then that Parse playlist Lambda function would essentially store all of the segment attributes of those video and audio tracks inside a DynamoDB table.

The Media Delivery side (Figure 12, below) is where the scheduling interface would be defined, and then the user, when they make a request for a playlist, would execute a Lambda function to generate a playlist. The user would come in via a CDN. That CDN would, based on the rules, make a request to an API gateway instance, and then that API gateway instance would be configured to recognize whether or not it’s a master playlist request or a child playlist request. If it’s a master playlist request, it looks up the channel’s table and returns all of the different tracks available in that channel. When it identifies a child playlist request, the Lambda script will look up inside the schedule table, figure out which piece of content is actually being played out, and how far into that piece of content the current schedule is. Then, in the assets table, it will look up which segment to insert into that playlist at what time. And then the actual media files are all pulled out of S3. So the media content I should say, is never processed. It’s simply sitting in an object store, such as S3 or another storage system, and it’s referenced by a playlist that’s being generated dynamically in a Lambda execution environment.

Media delivery

Figure 12. Media delivery

Next Steps

The next steps for this project relate to CloudFormation as an open source AWS solution: having the ability to insert an actual real live source rather than a VOD clip, to encrypt it and then have it served by a DRM-licensed key server (FairPlay, PlayReady, or Widevine), and then to build in support to generate an MPEG-DASH playlist.

The CloudFormation stuff has to go through our legal review to make sure that it’s not using any third-party libraries that don’t have the correct licensing terms to be used in such a way. Once that’s done, it will be released as an AWS solution, which allows you to essentially deploy the CloudFormation template in your own AWS account. That will allow you to modify it as you choose, and you will pay only for the underlying resources it uses. Of course you can turn it on or turn it off at any point in time--again, no commitments; you pay only for what you use.