A big part of our product at Lumen5 is our video rendering engine (we’re a video creation tool, after all). A couple of years ago, we started experimenting with WebGL as a potential new way to render videos. It’s totally transformed the way we think about JavaScript development, and opened our eyes to a completely different web paradigm.
When we first started, it wasn’t clear that WebGL was the way to go for us. It took a lot of research into the different alternatives before we broke ground on our existing render engine. I want to share why we thought WebGL was the best alternative for us in our situation.
The Problem and Requirements
Our users come to our website and interact with our video creator application to set up a series of scenes (which are combinations of text, images, videos, animations, audio, etc). When they are happy with their set of scenes, they click “render”. We needed something that would take that data and produce a final mp4 file.
The basic requirement: Take in some data (in the form of JSON + media assets) and produce an mp4 output.
Other requirements:
- The system should be scalable to hundreds of thousands of users creating videos
- The system shouldn’t cost too much to run (we understand that processing video is expensive, but let’s try to minimize where possible)
- The system should be able to render a video fast: it should be able to render a video faster than real-time (where one minute of video should render in less than one minute)
- The system should be able to show a user a preview of their video in real-time while they are creating it
- The system should allow us to have complete control over the rendered output (we should be able to control each pixel!)
Given these requirements, we set about analyzing a couple of alternatives.
Option 1: A Proprietary Tool, Repurposed as a Render Farm
Option 2: An Open-Source Tool, Repurposed as a Render Farm
Option 3: Use HTML + CSS + JavaScript
Option 4: WebGL
#javascript #ai #render #video #programming
