Show HN: Revideo – Create Videos with Code (github.com)
Revideo lets you create video templates in Typescript and render them with dynamic inputs through an API. It also comes with a <Player /> component that lets you preview your projects in the browser and integrate video editing functionality into web apps.
The project is useful for anyone who wants to build apps that automate certain video editing tasks. A lot of companies in the space build their own custom stack for this, like Opus (https://www.opus.pro/), which automatically creates highlight videos from podcasts, or Clueso (https://www.clueso.io/), which lets you create stutter-free product walkthroughs with AI voiceovers.
Revideo is based on the HTML Canvas API and is forked from Motion Canvas (https://github.com/motion-canvas/motion-canvas), a tool that lets you create canvas animations. While Motion Canvas is intended by its maintainer to exclusively be a standalone application [1], we have turned Revideo into a library that developers can integrate into their apps, while specifically focusing on video use cases. To support this, we have, among other things, added the ability to do headless rendering, made video rendering much faster and added support for syncing and exporting audio.
We’re excited about programmatic video editing because of the possibility to automate content creation with AI. One of our users is building StoriesByAngris (https://storiesbyangris.com/), which lets you create video-based RPG stories from language prompts. Other users are marketing-tech companies that help their customers generate and A/B test different versions of video ads.
We started to work on video tooling because we ourselves explored a bunch of product ideas in the space of AI-based video creation earlier this year. For example, we built apps that automatically create educational short videos and tinkered with apps that let you create memes.
While building these products, we were frustrated with the video editing frameworks we used: Moviepy (https://github.com/Zulko/moviepy), which we used initially, doesn’t work in the browser, so we’d often have to wait minutes for a video to render just to test our code changes. Remotion (https://github.com/remotion-dev/remotion), which we switched to later, is pretty good, but we didn’t want to rely on it as it is not FOSS (source-available only).
We had already followed Motion Canvas for some time and really liked it, so we thought that extending it would get us to something useful much faster than building an animation library from scratch. We initially tried to build Revideo as a set of Motion Canvas plugins, but we soon realized that the changes we were making were too drastic and far too complex to fit into plugins. This is why we ultimately created a fork. We’re unsure if this is the right way to go in the long term, and would prefer to find a way to build Revideo without feeling like we’re dividing the community - if you have experience with this (keeping forks with complex changes in sync with upstream) or other suggestions on how to solve this, we’d love your input.
Our current focus is improving the open source project. In the long term, we want to make money by building a rendering service for developers building apps with Revideo.
We’d love to hear your feedback and suggestions on what we can improv...
80 comments
[ 2.3 ms ] story [ 264 ms ] threadHow does this compare to Remotion^ which uses "React" mental model?
^: https://remotion.dev
Seems like there might be room for a "LangChain for Video" in this space...
What limitations are you hitting?
What’s your functionality wishlist?
First, we use generator functions to describe the flow of animations - every yield within the generator function corresponds to a frame in the video. As a result, our API feels quite "procedural" (animations described at the start of the function appear in the start of the video, animations described at the end appear at the end). Remotion's React-based approach is rather declarative - it gives you a frame number and lets you describe what your video should look like as a function of the frame number. Personally, we find our "procedural" API a bit more intuitive and easier to write than the declarative approach, but we might obviously be biased here.
Secondly, we render to the HTML canvas instead of the DOM. Both have advantages and disadvantages: Rendering to the DOM lets you define animations using CSS, which most programmers are already familiar with. On the other hand, an advantage of using the HTML canvas is that it should allow you to render entirely in the browser rather than using server-side rendering, as you can simply capture the current canvas using canvas.toBlob(). We have not yet implemented this for Revideo, but people in our Discord server have made good progress towards it.
Thirdly, we're MIT licensed while Remotion is not FOSS (if your company has more than three employees, you need to purchase a company license to use Remotion). As described in the post, this was one of our original motivations to build our own video editing framework while we were building video products.
Would you mind sharing a bit about your pivot? I always find these stories interesting!
Ideally, we would like Revideo to be used to build any kind of web-based video editor. A lot of video editors exist, and many of them make a lot of money. Based on my experience, building a video editor from scratch is also really hard - I would think that people would choose a framework that makes it easy to build them if it exists.
My biggest worry is more about the technical difficulty of the problem (becoming the standard way to build a category of products is probably not easy), rather than this being an actual problem. I'd love to hear your opinion though!
I wonder if there's opportunities for collaboration. It seems we're the only cloud-agnostic video embedding model that allows users to own their embeddings.
Here's a reverse video search tutorial: https://www.youtube.com/watch?v=H92cEhG9uMI&ab_channel=Mixpe...
There could be really interesting abstractions that people might build on top of this. Like automatically creating and animating infographics, making background sounds, or video cutting and recycling. If you spin this 100x further an entire video creation studio might emerge.
Which parts of Video Infrastructure do you want to build first? Which other higher-level parts could be built by you or users? Where could this go?
I'm glad you raise the point of reusability and people building abstractions - what I find really exciting about code as an interface for video editing (rather than GUI) is that it makes it much easier to create and share isolated, reusable components and functions. Especially as we are open source, I hope that many developers will build abstractions and share them on Github
Out of curiosity, what do you mean by "Video Creation Studio"? Would you add a visual interface for editing to Revideo?
https://motioncanvas.io/api/core/app/Renderer#render
However, this is not the only change we made. Our goal is (as stated in the Readme) to enable developers to build entire video editing apps with Revideo. This encompasses a few more things than just triggering headless renders. For example, here are some of the changes we made that were quite drastic and were not possible without forking:
- we export the audio of <Video/> elements in a scene. Enabling this required us to modify parts of the core package: https://github.com/redotvideo/revideo/commit/d0f72b6df68b380...
- we made video-in-video renders a lot faster by requesting video frames from a backend process rather than seeking video frames using the HTMLVideoElement API. This required us to make all draw() functions in Motion Canvas async: https://github.com/redotvideo/revideo/commit/a6e1bcdf0ca8200...
I’ve only skimmed the docs and nothing jumped out on this: would it be possible to use a 3d canvas context? For example, integrate a dynamic three.js layer/asset into the video?
Given that we are not a Retool competitor and operate in very different spaces, I would think and hope that this is not an issue for the Retool team
On a selfish note, as a canvas library developer/maintainer, I do have questions around your choice of Motion Canvas: what attracted you to that library in particular (I'm assuming it's the Editor, but could be wrong)?
On a broader note, my main interest in canvas+video center around responsive, interactive and accessible video displays in web pages. Have you had any thoughts on how you'd like to develop Revideo to support these sorts of functionalities?
Given that our goal is mainly to let developers build their own editors, the Motion Canvas editor is not that important for us - we only use it for previewing code changes, so merely projecting the canvas without any of the remaining editor interface would also be sufficient.
I also agree that interactivity is super important. We have not yet started to work on this, but something we definitely need to make easier with the Revideo player is building drag-and-drop editing features (i.e. moving elements around on the canvas to modify their position).