Elastic Transcoder Demo

About Elastic Transcoder (ET)

From the product page:

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.

Steps

ET requires a bit of configuration because it is comprised of multiple AWS services acting in unison.

1. On your AWS dashboard, select the ET service

   

2. Click Create New Pipeline. A pipeline is basically a "wiring" up of services needed to make ET work (e.g. S3, Simple Notification Service (SNS).

   It's advisable for the S3 buckets being created to be in the same region as the ET service to reduce latency (and thereby cost).

   

   Don't forget to add SNS notifications. These are basically interval webhooks sent to a public URL (which we'll configure later) containing information if the transcoding job has (a) started, (b) is progressing, (c) has failed, or (d) has succeeded.

   

3. We now configure notifications to send to our application's URL sending details of where the transcoding job is. You might be wondering how that's even possible, considering that we're developing locally. This is where ngrok shines. In a nutshell, ngrok allows you to create public-facing URLs for your local application by issuing a one liner on the application's working directory.

   Run ngrok http 8000 on your applications' current working directory and copy the public URL generated.

   

   Copy the ARNs of each topic we associated with the pipeline and set up subscriptions for them using our public URLs, using the aws/et/transcode/subscriber route (which listens for any webhooks sent by AWS' SNS).

   

   

4. View your logs in real time with tail -f storage/logs/*.log

5. Paste in the transcoding pipelines config values you set earlier as directives on the .env file:

   • AWS_ET_REGION
   • AWS_ET_PIPELINE_ID
   • AWS_ET_BUCKET_IN
   • AWS_ET_BUCKET_OUT
   • AWS_ET_BUCKET_THUMBS

6. Run php artisan config:clear.

7. Send a POST request to the aws/et/transcode URI. It should contain the file that is going to be transcoded. You can get a few free ones here:

   

8. You should start receiving a continuous stream of notifications from AWS on where the transcoding job is at:

   

   (In this case, it took less than 10 seconds for it to finish.)

9. Visit the bucket that stores transcoded files. Notice that the file has shrunk from 32MB (1920x1080) to a measly 1MB (320x240) after being transcoded and compressed in a matter of seconds, a fraction of the time it would have taken compared to transcoding it on a typical local server:

   

Questions

Why Elastic Transcoder? Why can't I just use my own hardware to transcode the video files.

It comes down to scalability, concurrency, and ease-of-use.

Suppose you are developing a high-traffic e-learning application. On spurts you get hundreds of students who, all at the same time, upload their assessment submissions in the form of video files. Thing is, they have neither time nor patience to figure out how transcoding and compression works. They just want to upload straight from their phones.

A bunch of them upload uncompressed videos in varying formats and containers (e.g. mp4, avi, mkv). What's even startling is that some of these 20-second videos reach up to 500mb because these were recorded in 4K. Your server doesn't have that much local storage.

The solution to this is Elastic Transcoder (ET). With ET, you only pay for the resources you use -- AWS does convoluted process of:

1. Transcoding the files into a common container format,
2. Compressing them to reasonable file sizes, and
3. Storing the files in the cloud (via S3)

---

Can we use a different transcoding preset?

Yes, of course. There are a variety of presets available at your disposal. For this demo, I've set the default preset to be 1351620000001-000061 (Generic 320x240).