Top 10 things to consider when migrating your VOD library to AWS

There are lots of things to consider when moving your VOD (Video On-Demand) content library to a new provider like Amazon Web Services (AWS). In this post, we cover the top things to keep in mind when migrating media files to AWS.

1. Should I migrate my currently encoded files or should I re-encode my library?

The easiest way to move content to AWS is to simply upload your existing encoded files into Amazon Simple Storage Service (S3) and continue using them without reprocessing. If your workflow involves AWS Elemental MediaPackage to handle packaging, DRM, or time delay, then this is the easiest path. For example, if you are only delivering HLS and have no plans to alter your bitrate ladder, you can use Amazon S3 as your origin and deliver video using the Amazon CloudFront CDN.

You may decide to add an additional rendition to your existing adaptive bitrate ladder, often at the top end given the ever-increasing bandwidth and resolution of end user display devices. You can do this by using AWS Elemental MediaConvert to transcode additional renditions and then update your existing manifests to include the new renditions.

The biggest reason to re-encode your content library is to reduce storage and delivery costs. If your content is encoded with AVC, migrating to a new codec such as HEVC will increase efficiency and lower your costs, even if only some of the players you deliver content to support this codec. You can also encode source videos with MediaConvert using a more intelligent rate control mode such as QVBR (Quality-Defined Variable Bitrate). QVBR can reduce the size of your encoded files by up to 50% over CBR mode. Plus, QVBR is simple to use, works with any type of source content, and encodes at the highest video quality using the fewest bits. QVBR works with either the AVC or HEVC codec and is available at no additional cost.

2. Which codec should I choose, AVC or HEVC?

Many legacy devices don’t have the ability to decode HEVC, so if your target audience relies heavily on those, you’ll likely need to retain your AVC renditions. Since the Apple HLS specification does not allow for mixed AVC and HEVC stacks, you can’t simply add your HEVC output. If you want to target devices that support AVC and HEVC, then you will need to generate two separate ABR ladders.

If your target devices support both AVC and HEVC, then it’s always worth the up-front investment in HEVC. Assuming your model is mass distribution, the cost savings on your distribution and storage quickly surpass the added cost of using the AWS Elemental MediaConvert professional tier encoding, which is required for HEVC outputs. To that point, even if you still require AVC for some devices, adding HEVC to your workflow, coupled with QVBR, is a good investment in the long run.

3. Which rate control mode should I use, CBR or VBR?

As mentioned above, you should actually consider using QVBR. For most iOS and Android devices, using QVBR with quality level 7 works well. For large TV displays, using quality level 8 or 9 will give viewers better results. With QVBR rate control, it’s really that simple. Unless you’re targeting a legacy playback device that can’t handle fluctuation in bitrates or technically requires CBR, using QVBR will save you money while maintaining excellent video quality.

4. Should I use HLS or MP4 as the origin source format for my CDN?

Because AWS Elemental MediaPackage can ingest either HLS .m3u8 assets or .smil assets, you can simplify your workflow by using MP4 files as your origin container. MediaConvert will generate fewer files using this process, and the final outputs can still match what you could generate if you were to export HLS from MediaConvert. This method also lowers S3 GET requests when packaging and delivering to Amazon CloudFront. Another important benefit of MP4 files as your origin source is that even if the HLS specification is updated (which it often is), nothing needs to change on your end to take advantage of the updates once MediaPackage incorporates the additions. In this way, you’re future-proofing your HLS delivery. If your end goal is to generate “simulated live“ linear channels through AWS Elemental MediaLive using your VOD content, then keeping the files as MP4 also allows you to take advantage of dynamic inputs.

5. When should I use encryption to protect my content?

Depending on the security requirements of your video assets, you may opt to forego encryption altogether. Many customers who do require encryption will leave their source assets in an S3 bucket with encryption-at-rest handled server-side by SSE-S3. If you encrypt the source asset before storing it in S3, then anytime you want to view this asset you must decrypt it using the matching key. This adds a layer of complexity to any QA or internal workflows where you need to examine the source asset. Since AWS Elemental MediaPackage allows you to handle just-in-time encryption during the packaging process, this becomes a more suitable point for the encryption to occur. With MediaPackage handling encryption, multiple DRM providers can be used and multiple output formats (HLS, DASH, MSS) can be generated at any time.

6. How many renditions should I generate for my ABR output?

Making resolution and bitrate decisions for your ABR outputs is critical. Even if you use QVBR, you still have to choose the the resolutions and quality level settings for your content. You don’t want to pay for transcoding, storage, and delivery of outputs that are not going to be viewed by your end users. For the same reason, if all of your users’ devices can decode HEVC, you wouldn’t want to pay for AVC transcodes. We often point customers to Apple’s HLS specification, which includes the base ABR ladder recommendations. Gathering metrics about how end users are viewing content becomes critical in determining if some renditions are needed or if they can be removed. The key is finding the right balance between handling bandwidth fluctuations without having your users switch bitrates too often during viewing. Bryan Samis wrote a great blog post about detecting devices and serving only the necessary renditions. If you pair this type of functionality with metrics around buffer time, viewing duration, and bitrate switch occurrences, then you could automate the removal of less performant outputs.

7. What settings should I be using for Group of Pictures (GOP) and slices?

Generally, the more I-frames in your video, the higher the bitrate, so choosing the right amount of frames in your GOP is critical to maintaining a target bitrate while keeping quality high. When setting up outputs in MediaConvert, we generally recommend 2-second GOPs. This fits nicely with Apple’s 6-second segment recommendation for HLS and works well with DASH-ISO packaging in MediaPackage. The segment length you choose must be divisible by the GOP length or the player can have issues. The settings for slices are similar, but within the frame itself. If you try to encode a 4K (UHD) output with 1 slice, you’re going to end up with a lower quality output than if you set it to 4 slices. If your output is 720×480 (SD resolution), 1 slice works just fine.

8. What about storage?

When it comes to storage, you should take advantage of simple cost-saving features. First, when your transcodes and QC process are done, you should move your master (source) video files to Amazon S3 Glacier. Second, assuming Amazon S3 is the origin for your transcoded assets, you can take advantage of S3 Intelligent-Tiering, which will automatically move assets between S3 tiers based on their utilization. Finally, don’t forget to take advantage of S3 Events to create a watch folder to kick off MediaConvert jobs using AWS Lambda.

9. How do I monitor my transcoding in AWS?

We recommend using Amazon CloudWatch Event Rules to monitor when MediaConvert jobs complete. A simple snippet of code can monitor the success or failure of each job, and the code can easily trigger Lambda or SNS to keep a workflow moving along.

10. How much will this cost?

Given all of the above, there are going to be some calculations involving cost and ROI when re-encoding your content, especially if you are considering moving from AVC to HEVC. Stay tuned for a future post with some pricing examples for VOD transcoding, storage, and delivery using AWS.

Conclusion

Hopefully, this post gets you thinking more about some of the considerations you’ll face when porting your content library to AWS. Once your content is uploaded to Amazon S3, there are lots of possibilities. As a next step, try exploring the Media2Cloud solution, where you can gain more insight using media analysis tools and make your content even more valuable. You can also get a jump start by using the Video on Demand on AWS solution, which automatically creates a solution that can ingest metadata and source videos, encode videos for playback on a wide range of devices, and deliver videos to end users through Amazon CloudFront. Get started today!