Securing Videos on your sites using AWS ElasticTranscoder and HLS — Part 2

Akshat Priyansh
5 min readMay 6, 2019

--

In the previous post, we have gone over the entire procedure of performing the method. We will now explore the procedure in a dissected manner.

In this post, we will be setting up our AWS S3 Bucket and ElasticTranscoder Pipeline

Creating and Configuring our S3 Bucket

The way HLS works is by using a master playlist file which points the media player to the URLs of the encrypted media files.

Therefore, one of the things we need to do is to have a storage space for our original media files and their encryption counterparts (.ts files & .m3u8 playlist files). Some of these files need to be public, whereas some need to be private.

Head over to S3 and create a new bucket. I have named mine hls-medias. Click on Properties and use this configuration so that our Bucket can be public but have private objects.

Bucket Properties

Also, modify the CORS Settings to contain this piece of XML. This is ensure we don’t get cross origin errors when requesting media files from AWS S3 to our own domain.

<?xml version=”1.0" encoding=”UTF-8"?> <CORSConfiguration xmlns=”http://s3.amazonaws.com/doc/2006-03-01/">   <CORSRule>     <AllowedOrigin>*</AllowedOrigin>     <AllowedMethod>GET</AllowedMethod>     <AllowedMethod>HEAD</AllowedMethod>     <MaxAgeSeconds>3000</MaxAgeSeconds>     <AllowedHeader>*</AllowedHeader>  </CORSRule> </CORSConfiguration>

Structuring our Bucket

One of the reasons why this is important is because we need to configure our CloudFront CDN to serve assets from a single bucket. We can access private content using something called Signed URLs.

Make a folder inside your bucket. Let’s name it HLS. In the root of the bucket, we will be uploading our original media files which we want serve using HLS.

Sample image of how our S3 bucket should look

Setting up Elastic Transcoder

Amazon Elastic Transcoder is media transcoding in the cloud. It is designed to be a highly scalable, easy to use and a cost effective way for developers and businesses to convert (or “transcode”) media files from their source format into versions that will playback on devices like smartphones, tablets and PCs.

We will be using Amazon Elastic Transcoder to transcode our files into HLS and store them in our S3 Bucket.

Creating our Elastic Transcoder Pipeline

Note : The IAM role might not be visible right now but after creating the Pipeline the default role will be created with the same name. We will be using this role later.

Configuring our HLS Pipeline

Issuing Elastic Transcoder Role required Permissions

For starting to create Encrypted HLS Content, we first need to create a KMS Key and give it appropriate permissions. Go to Amazon KMS and click on Customer Managed Keys > Create Key.

Give it a name and quickly come to the third screen starting Define key administrative permissions. Search for the IAM role you provided in ElasticTranscoder and give it administrative and usage

Administrative Permissions
Usage Permissions

Associating generated Key with Pipeline

After the key is generated, copy its ARN. Go to Amazon Elastic Transcoder and edit the Pipeline we just created. Scroll down at the bottom to find Encryption section. Click on Custom and paste the ARN you just copied.

Pipeline Encryption

We can now start issuing jobs to create encrypted HLS media files out of files in our bucket. Lets create a new Elastic Transcoder Job.

Enter output key prefix as HLS, and this will be the folder contain our output files. Select the video you want to encrypt.

Creating your first HLS Job

Creating a new Job

Note: The output key needs to have the format of output* to be considered as public according to our Cloudfront behavior, which we will configure in our next post.

We are going to create two outputs for every single media file we want to encode, one for the video channel and other for the audio channel.

Output Preset 1: HLS 2M

HLS Video file preset

Output Preset 2: HLS Audio 64k

HLS Audio file preset

Create Playlist file

At the bottom of our job configuration, we will have an option to create a playlist file. Choose that option and give it a name. This will create the master playlist, the last ingredient we need to finish our HLS Configurations.

For content protection, it is always a good idea to store the key at your end. Choose No Store options and create a GET route on your domain. Put the route in the License Acquisition URL option. This URL will be included in the playlist and will be referred each time the media player encounters an encryption media file.

The URL should be able to return the data key in the correct format which is required to decrypt the .ts files.

We will cover this area in the further posts. For now, just create a route and mention it while creating the job.

We are using HLS v3 for this Demo.

Changing Permissions of the generated files

Once the job is completed, a lot of files are going to be generated in our HLS folder.

We need our main playlist file — GothicxDemo.m3u8 to be private. This file should only be accessible through signed URLs. All other files generated by the job should be public.

Select all files EXCEPT the main playlist file (GothicxDemo.m3u8), right click on them and click on make public.

This will ensure that when the media player is fetching videos, it is not doing so by signed URLs. These files need to be public as HLS is not supported by signed URLs.

Making all files public except for the Master Playlist file

Thats it for this post guys. In the next blog post, I will show you how to setup our CDN to use signed and unsigned URLs to fetch assets from our hls-medias bucket.

--

--