Server-less Video Backend
In this blog post by Jonas Rydholm Birmé he describes how a completely server-less video backend on AWS would look like.
When designing our proof-of-concept of a fully cloud based OTT-only playout I used AWS Elastic Transcoder to produce the example content in HLS. Continuing that line-of-thought I was thinking on how a completely server-less video backend on AWS would look like. In this blog post I will describe the design for such a server-less video backend.
Before we begin let us define what I mean with a video backend in this scenario. A video backend could be an entire online video platform including video management, entitlement, metadata and rights management, but in this scenario I have scoped it down to only include the video management. Metadata, entitlement and rights management are handled in systems / components outside of this design. Now with that sorted out let us look at the different parts of this system.
Content Ingest
An operator needs to be able to add content to the video backend and to facilitate this we need a user interface. This user interface was developed as a Javascript application and served by a static HTML document stored in an S3 bucket. To distribute the HTML over HTTP and Internet I used an AWS Cloudfront distribution with this bucket as the origin. No need to setup a web server or NodeJS application as the HTML content is static.
When an operator wants to upload a video file, the Javascript application handles the upload of the video file to an S3 bucket using the AWS S3 SDK, and creates an AWS Elastic Transcoder transcoding job created by a Lambda function (Ingest Service). This Lambda function is exposed as an HTTP REST resource endpoint using an AWS API gateway.
The AWS Elastic Transcoder transcoding job is created using the AWS SDK, something I described in an earlier post on how it can be done, and in this case I wanted the output to be HLS. To describe what this Lambda function does I will show you the manual process that this Lambda function automates.
I have prepared a pipeline where we will put the transcoder job. The pipeline is configured with which S3 bucket to find the source video file and which S3 bucket to write the output HLS to. The output key prefix is the name of the directory where it will place all HLS segments and manifest files. Input key is the name of the source video file to transcode.
I created a number of outputs and used the system presets HLS 2M, HLS 1M and HLS 600k. Specified that each video segment duration is 8 seconds and output key is the prefix of each segment.
I place these outputs in an HLS master playlist and I specify to use HLS version 3 in this case. Once the transcoding job is completed the HLS files are stored in the S3 bucket (HLS Storage) as configured in the pipeline.
Content Distribution
To access the content of this HLS Storage S3 bucket I use another Cloudfront distribution with the CNAME maitv-vod.lab.eyevinn.technology.
To playback the HLS you just point your HLS video player to play for example the URL http://maitv-vod.lab.eyevinn.technology/stswe1/master.m3u8. You can use the native player in Safari to try it out.
This URL is associated with an asset ID and stored in an AWS simple database (e.g. DynamoDB) by the Ingest Service Lambda function.
Content Access
As we have decided that this video backend does not handle metadata and content discovery, we will assume that in this scenario the client application already has the asset ID for the content it wants to playback. And we also have no entitlement controls in the video backend so the only thing the client application needs is the asset ID now. To be able to obtain the URL to the HLS, another Lambda function (Video Assets Service) is used, and similar to the Ingest Service this Lambda function is exposed as a REST resource using an API gateway. This Lambda function performs a lookup in the database and returns the HLS URL to the client. This HLS URL can then be passed to the video player in the client application.
To summarize, in this post I have described how to build a video backend that manages Content Ingest, Content Access and Content Distribution without using a single server instance on AWS. Using this server-less approach means that you would only pay for the storage used and the processing power consumed. When the system is idle you basically pay nothing. I leave it now up to you as a reader to do the calculations on whether this approach is financially more beneficia for youl. Hope you’ve enjoyed the read!
Jonas Birmé is a Solution Architect at Eyevinn Technoloy. A Swedish based independent consultancy company specialized in the video and streaming technology.
