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

How to Build Live Linear OTT Channels in the Cloud

Is Cloud Playout Possible?

But what is a channel, and what is a channel in the cloud? It’s essentially a series of VOD clips, and this concept of taking pre-recorded content and transforming it into a live stream—i.e., VOD to live—isn’t really that new.

But at a more basic level, a channel is a playlist describing media segments, and you can generate that playlist any way you want. It doesn’t have to be done by the encoder, or by the playlist generator from the packaging system. It can be done completely out of band, and however you want to generate that playlist is up to you.

So, is it possible to reuse an SVOD library, an AVOD library, or any type of VOD library that's sitting inside S3 and re-purpose that to create a live linear channel (Figure 5, below)? I wanted to test if this was possible, theoretically and technically possible, so I set up some goals. The idea was simulate the exact characteristics of a linear OTT stream, including ads. I also knew that we’d need to build a scheduling interface. A linear TV channel doesn't make any sense unless you can schedule what comes after what in a linear playout fashion.

Is cloud playout possible

Figure 5. Can it be done?

I also wanted to achieve Netflix-quality video--that is, VOD quality in a live stream, which typically is not the case. I wanted to decouple encoding from playout, which is really the crux of the whole solution in that you encode all of your assets one time and then play them out as many times as you put into the schedule without ever having to re-encode. I also wanted to decouple the concept of latency from the forward buffer. One of the biggest contributors to a latency in an OTT experience is the fact that the client generally is buffering multiple seconds of video, and usually it’s equivalent to three segments of the playlist (at least with HLS and Apple).

But if I know the schedule ahead of time, I can basically make the segments in the playlist segments go three segments into the future, thus making a zero-latency stream relative to my schedule that still has a very healthy forward buffer. I also wanted to ensure that I was reusing a cache as much as possible. If somebody had watched a title in an SVOD or an AVOD or a catch-up experience, I wanted to reuse that segment in the CDN because that means that the CDN doesn’t have to go back to origin to serve the same content, which increases performance and decreases costs.

Finally, I wanted it to be entirely serverless and automated, which is important because you’re defining your infrastructure as a piece of code. One single text file describes 20 or 30 different components that all talk to each other without ever having to physically think about a physical device. That means I can spin it up in any region on the AWS cloud in any part of the world. I can also turn it off completely when I don't need to use it, and I can scale it up and down very rapidly.

Demo

Below is a demo of what this looks like that I presented live at Streaming Media West.

What it Costs

I just wanted to add some numbers in terms of how much this costs to run the demo (Figure 6, below). Let’s say I had 100 unique, 40-minute shows for playout, and each one of those shows was used 100 times in that month (with some repetition), and I had six H.264 bitrate renditions, one audio bitrate, which is fairly common to have that sort of setup. These would be your indicative costs. You would have to store those assets in S3; that would cost roughly a dollar. You’d have to generate the playlists, which are then cached by the CDN. That would cost roughly a dollar. You would have to convert all of those assets into the multi-bitrate renditions. That would be your biggest cost by far.

Monthly cost breakdown

Figure 6. Monthly cost in USD

And if you are reusing the content, you don’t pay for that incrementally. You pay once, and then you can deliver it as many times as you like after that. You’d have to store the schedule and all of the asset metadata so the playlist channel already knows where all the segments are in the file. You’d need to invoke API gateway as sort of a front end to Lambda Executions. Both of those things would roughly cost you a dollar each. So, the total cost to run a channel with a hundred assets including the encoding would be around, as shown in Figure 6, $16-18/month per channel. Obviously, that doesn’t include CDN costs or delivery costs.

Lessons Learned

Here are some lessons I learned from this experiment that may be useful to anyone thinking of trying to build a live linear channel with cloud playout.

Discontinuity: Inside the HLS playlist is the concept of a discontinuity and a Media Sequence ID. This is of paramount importance. Every single time one of the top segments goes off a rolling window playlist, you must increment that. That may be a Sequence ID, so the HLS decoder knows that this is a new playlist, not an update of the previous one. Every time you increase that number, if you look inside the console of your HLS player you’ll see it starts a new render chain. It’s very, very important that the player knows about the Media Sequence ID and this is consistent. You can’t skip numbers, and you can’t forget to increase them; otherwise, playback will stop.

HEVC: The next lesson learned concerns using HEVC as a codec. During my experiments, the Grand Tour title that you saw was HEVC-encoded plus quality-defined variable bitrate encoding and two-pass encoding (HEVC + QVBR + 2-pass). That resulted in roughly a 50% bitrate saving, but it was 10 times the cost of doing the same thing with H.264, one-pass with our QVBR. QVBR is actually free. There’s no incremental cost if you’re using QVBR. So I definitely recommend using that in any case. But two passes are quite expensive, and HEVC, for licensing reasons, ends up being about 10 times the cost. But it’s actually worth it in a lot of cases because you're encoding once and reusing many times you're amortizing that 10X cost over a much longer period and ends up paying for itself over time. So if you have 500 assets that need to be encoded in a given month, but you’re going to play them out in a rights window over the next six months, every time that gets played back, your 50% bitrate savings add up. It adds up on the CDN usage, which can, in a lot of cases, cover the 10X in costs. And of course with HEVC your users will have a much better-quality experience for the same bit-rate.\
Use the lambda instance store: Inside Lambda there is a small instance store. If you’re making constant calls to a database to pull a schedule, you should use that as much as possible. If you have lots of users requesting a playlist--even though it’s cached by the CDN--they still need to get an update every segment duration, and you want the Lambda instance when it runs to remember the database call that it did before.

Zip large text in DynamoDB: Inside DynamoDB, if you’re storing a playlist file describing every single segment in that video track, zip it. You can zip things inside DynamoDB and then unzip them inside Lambda. That ends up being a lot faster.

Use CloudFormation for everything all the time: If I were developing something new off the bat—even if I were purely experimenting and had no intent for it to become production-worthy--I would still use CloudFormation because it allows me to develop much faster, deploy changes, and keep track of things. It’s just a better tool in all cases. When you get to the production sense, you can implement a DevOps-type pipeline, and then having everything defined as code will pay enormous dividends as you have to maintain it over its lifespan.

Previous Page Next Page