justusm

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.

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).

- 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...

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)