nice! Training models using reward signals for code correctness is obviously very common; I'm very curious to see how good things can get using a reward signal obtained from visual feedback
Revideo is different to Remotion.dev in a couple of ways:
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 is very imperative (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. Also, capturing the frame for videos is a bit faster than screenshotting it (as Remotion does), so our rendering speeds are faster than Remotion's.
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). This was one of our original motivations to build our own video editing framework while we were building video products.
This is really cool - I'm currently building something similar (open source) with Revideo (https://github.com/redotvideo/revideo) - we also build on top of the webcodecs API, the only part of the export that is still done on the server is audio processing.
It seems pretty unconventional to offer an sdk where people have to enter a license key, but I understand that it's hard to monetize differently when one of your key features is that you want to enable client-side rendering (not saying that this is bad - I relate to the challenge since we are offering a cloud rendering service and at some point when webcodecs is supported in all browsers, it might make sense to run revideo purely on a client device as well).
You can use the render function from motion canvas to trigger headless renders (which is what we do!) without forking the project.
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 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...
In the simplest form: Revideo is MIT-licensed. That basically means that you can do anything you want with our code - you can modify it, fork it, build commercial products, resell it, etc., without owing us anything.
While you can look at Remotion's code on Github (that's what we mean by source-available), the project has a custom license that doesn't grant you the permission to do anything you want with it. Remotion retains ownership of the code (i.e. you cannot simply fork it and give it away for free), and when you are a company with more than three employees, you have to pay Remotion if you want to use their code to render videos
Thank you! A lot of people have mentioned this to us already - we did not think about the LLM use case when getting started with Revideo, but it does make a lot of sense that it can be used to build text-to-video products and fully automate video editing.
As you mentioned, letting LLMs generate high-quality Revideo code is probably not yet possible, but something I believe could make a lot of sense is using LLMs to choose parameters for your video. Video parameters can get as complex as you like in Revideo (any JSON object is accepted), so you could build a very flexible template that lets you define pretty much any video by using a "universal" JSON representation (essentially, this would be a list of elements such as audio files, videos, images, texts, along with attributes describing the timing, position, etc. of the element)
Letting the LLM generate input variables for your template instead of the code would at least allow you to do type checking and ensure that there are no bugs in your video code - however, I still doubt that the resulting video will be of high quality, LLMs are probably not yet smart enough for this.
The best way to get started if you want to build a simple editor is our Saas-Template. It's a simple NextJS app that embeds the Revideo player and lets you export your video with a button click: https://github.com/redotvideo/examples/tree/main/saas-templa...
To learn how you would build a template for video splitting, feel free to check out this example: https://github.com/redotvideo/examples/tree/main/stitching-v.... It shows how you can render and concatenate videos for desired timestamps (e.g. show only second 5 to 10 of a video)
Glad to hear that! I would say that the choice of Motion Canvas was motivated by their API for defining animations rather than the editor - we really like the approach of using generator functions and find the "procedural" API (the time of the yield corresponds to the time in the video) quite nice to work with.
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).
Justus here, I'm one of the co-creators of Revideo. I agree that there's a high similarity. We unfortunately only noticed this a few weeks after launching - our logo was inspired by the tracks you see in video editors.
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
Thank you! If you have any questions or run into issues, please let us know! You can find out Discord server in our repo or can email me at justus at re.video
no worries at all - I appreciate the feedback. Out of curiosity, what makes you think this is a tarpit idea? I roughly understand the term as "ideas that seem obvious and easy, but have non-obvious problems".
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!
Revideo is different to Remotion.dev in a couple of ways:
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.
Thanks for the feedback! Justus here, I am one of the co-creators of Revideo. Initially, we intended Revideo to be a developer tool and not necessarily something that could be modified through a user interface. However, we've heard this feedback many times at this point, so we're definitely considering building editing capabilities into the UI. One challenge here is to find a way to keep the UI changes and the code in sync.