Building Serverless Media Functions

In this blog series I will describe how a serverless infrastructure for media functions can be implemented. A media function can for example provide the functionality to analyze and obtain information about a media file, crop a video, generate keyframes for all scenes or create a proxy version of a master. In this first article I will show an example of a simple media function that can be used to obtain basic information about a video file. This article is written by Jonas Rydholm Birmé, streaming video specialist at Eyevinn Technology.

Jonas Rydholm Birmé, Streaming Video Specialist, Eyevinn Technology

What is a Media Function?

My definition of a media function is a stateless microservice that provides a very specific service. What differs a media function from another function is that it has some media processing involved which have some implications on the underlying infrastructure. I will be using Docker and the AWS managed Kubernetes service (EKS) but the principles I describe can be used with other cluster management frameworks and running on other cloud infrastructures, or even on servers on premise.

Media Function Probe

This simple media function will be parse the headers of a media file and output a JSON object with all the information about the media. What tracks or streams it contains and information about media codecs, framerates etc. It is based on the ffprobe command that is included in ffmpeg, so the first thing is to build a Docker image with ffmpeg. I choose to compile ffmpeg from scratch as I can choose more granular what features I want to include in the build. I am compiling ffmpeg to include the following:

In short it includes support for the video codecs AVC, HEVC, VPx, AV1 and audio codecs AAC, Opus and MP3, and in addition also support for SSL which is needed to read files over HTTPS.

This is built into a base container (ffmpeg-base) that will be uses as a base for the media function Docker container.

To provide an API to this functionality I built a NodeJS server application based on the NodeJS library Restify. Based on this framework two endpoints are provided, a health check endpoint (HTTP GET) and the main endpoint for this media function (HTTP POST). To use this media function a request with a payload containing the URL to the media to probe is sent to this endpoint. The payload is a JSON structured payload and in return the ffprobe output is returned as a JSON object. A request can look like this:

To execute the ffprobe command I used the fluent-ffmpeg NodeJS library which is a wrapper and helper library to construct and run the ffmpeg and ffprobe commands. It requires that ffmpeg and ffprobe are installed on the operating system where this NodeJS service is running. This is where the concept of containerization works very well. We will create a new Docker image and container that is based on the ffmpeg container we just created, and where we install this NodeJS server application. The Dockerfile for this container looks like this:

On top of the ffmpeg container we install NodeJS and copy the necessary files for the NodeJS application we developed. To provide API documentation and an interactive user interface to try it out we use SwaggerUI and a service definition based on OpenAPI 3.0.0.

Once the Docker container is built we can try it out by running:

And then enter http://localhost:8080/ in the web browser and with the help of SwaggerUI can try it out. We can also use curl or Postman to try it out.

One thing you might ask is how to work with this setup during development. Do you have to build a new image and container for every change to the source code of the NodeJS app?

The way I found to solve this, but there might be other solutions as well, is that I run the container in interactive mode and mounts the current working directory to a working directory on the container, for example:

Then I find in the directory /appdev within the container the source code and can manually run the NodeJS application there.

To summarize, we now have a Docker container providing an API function to analyze and probe a media file. In the next blog post of this serie we will have a look at how we can provision this container and run the media function on a cluster. All the above mentioned source code is available on our Github.

Thank you for reading and if you have any comments or questions please join the conversation in the Streaming Tech Sweden slack.

Eyevinn Technology is the leading independent consultant firm specializing in video technology and media distribution, and proud organizer of the yearly nordic conference Streaming Tech Sweden.

Next post >>>

We are consultants sharing the passion for the technology for a media consumer of the future.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store