[justusm]

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

[bgrigore]

Thanks! I checked out revideo a while ago, and you guys are doing a fantastic job!

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.

[justusm]

Thanks a lot, really appreciate it! Re pricing: this might be my own ignorance then.

I will definitely follow you guys, I'm curious how rendley will develop :) Good luck!

[nikshepsvn]

how does revideo compare/differ to remotion?

[justusm]

Hey! I'm pasting a slightly modified comment from our previous Show HN (https://news.ycombinator.com/item?id=40646741), where I explained this in detail:

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.