Video content is more popular than ever, but the toolkit for creating such content is a bit behind. You usually have to rely on a server for rendering whenever you want to create a video editing project in the browser. This means uploading content to a server, coding complex filters and effects, and more.
My friend and I spent a year developing an SDK that handles all these complexities and offers an easy-to-use interface for developers. The SDK works entirely in the browser, manages memory efficiently so it can run even on a 7-year-old Android device, supports GLSL effects and transitions, handles captions, and much more.
We also created a custom video editor UI interface using the SDK to showcase its speed and flexibility. You can see the video editor embedded on our landing page: https://rendley.com.
As for the tech stack, the SDK was built using TypeScript, Pixi.js, C++, FFmpeg WASM, and WebCodecs. The UI interface was created using Stencil.js and MobX.
The SDK is called Rendley SDK and it is live on npm: https://www.npmjs.com/package/@rendley/sdk
To get started, follow this guide: https://docs.rendley.com/installation
If you want to embed the pre-made interface, follow this guide, it’s literally a few lines of code: https://docs.rendley.com/video-editor
If you have any questions about the product or any feedback, feel free to write them below, and I’ll be more than happy to answer them.
Note that a lot of the ffmpeg code is not memory safe and some of the file/codec plugins contain memory errors. An out-of-bounds read or write will bring down the entire wasm subsystem (and does). You have to manually figure out which codecs are actually safe to use in the browser, vs which ones are merely exposed by the ffmpeg wasm builds.
Edit: it was updated and now mentions forking modules but still no public repositories.
Deleted Comment
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).
I don’t think it’s unconventional for SDKs to require a license key. It's a common practice for many products.
To address the use case where WebCodecs is not available, we’ve implemented a rendering mechanism based on FFmpeg. Although it’s slower, it does the job (It's not enabled in the current version of the package)
Cloud rendering is a great approach for certain scenarios, and we also plan to support that option in the future.
I will definitely follow you guys, I'm curious how rendley will develop :) Good luck!
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.
Deleted Comment