The Eyevinn ingest application framework: making ingest flows modular
Published: 2021-08-31 14:00:58

One issue every VOD streaming service faces is that of ingest handling, i.e processing content as it is delivered from one or more production pipelines to be transcoded for viewing on your service. 
In theory, this is a simple problem to solve: when production sends a file to the agreed upon location, send it to your transcoding service of choice, and publish the result on your CDN. However, it isn't as easy in practice, since there's a lot of variability in the specifics.
Let's look at the delivery of the files, for example: are they sent to a location on the same computer your ingest application is running on, a network drive, or maybe a cloud storage service? How is the video transcoded? There are a number of commercial transcoding services out there, or you might have an open source or in-house solution.

As you can see, building an ingest application can quickly become a headache. At Eyevinn, we've experienced this first hand. That's why we came up with the **Ingest Application Framework**.

## The framework
The idea behind the Ingest Application Framework (IAF for short) is to provide a modular solution to a modular problem, and simplifying the building of VOD ingest applications.
It is based on plugins that interact with some storage or transcoding solution. Developers can use the plugins they need for their specific use case to speed up implementation.
![A diagram of the Eyevinn IAF structure](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v9t1mg3rpyfjvjkutd84.png)

## The plugins
Plugins can for example watch a storage space for new additions, or [handle uploading and transcoding video on AWS](https://github.com/Eyevinn/iaf-plugin-aws).

When we designed the IAF, we wanted to boil down the interfaces to the essentials for two reasons: to make building an app on top of the IAF as smooth as possible, and to minimize the constraints for plugin developers.

Anyone can write an IAF plugin to suit their specific needs. 
If you do, consider making it open source and publishing it to NPM!

## Writing a plugin
As we explained earlier, the interfaces for writing an IAF plugin are intentionally sparse, but that doesn't mean that your plugin has to be! As long as you implement the correct interface (`IafUploadModule` or `IafFileWatchModule`) for you needs, you're free to do what you feel is needed for your implementation. Let's use our own [AWS transcoding plugin](https://github.com/Eyevinn/iaf-plugin-aws) as an example!

Our main module, the `AwsUploadModule` implements the `IafUploadModule` interface, but also expands upon it. Under the hood, we have modules that interact with S3 (as a middle point, since MediaConvert requires HTTP inputs to e publicly accessible), and AWS MediaConvert. The rest of your IAF application doesn't need to know that though; all it needs it the `onFileAdd` method, which promises to take care of any files added to you ingest location.
If you want to look at the code, [the GitHub repo](https://github.com/Eyevinn/iaf-plugin-aws) is publicly available, and the plugin itself is freely available for you to use in your own ingest applications.

## Closing words
The IAF is still a work in progress, and we encourage readers to keep an eye on the [website](https://eyevinn.github.io/ingest-application-framework/) for changes and news. We hope that the IAF will be able to help developers build their own ingest applications faster, and remove some of the complexity from the process.

*Eyevinn Technology is the European leading independent consultancy firm specializing in video technology and media distribution. If you need assistance in the development and implementation of this, our team of video developers are happy to help out. If you have any questions or comments just drop us a line in the comments section to this post.*