Show HN: Revideo – Create Videos with Code (opens in new tab)

I agree! We were definitely motivated by the emergence of AI tools for video when building Revideo - as mentioned in the post, we think that a lot of video creation can be automated using AI. Currently, there are probably some higher-priority challenges related to the core rendering library that we need to solve, but we’ve definitely already thought about building a universal client library for common AI services that are useful for generating videos (e.g. text-to-speech, text-to-image, text-to-video)

Thank you, I'll try to disable it! I noticed the little yanks too but didn't know where to look and therefore didn't take the time to try and get rid of it.

Just checked out the demo, nice work!

Thank you! As of now, many people use Revideo to programatically create Youtube videos (primarily entertainment content, think of AI generated memes and Youtube Shorts) and for use cases in video marketing (think automatically generating and A/B testing ads from a product portfolio). As the project becomes more mature and better, we want to enable developers to build more complex, and especially interactive video editors using the framework.

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?

We tried to reach out to Jacob but unfortunately didn't get a response from him. In general, Revideo and Motion Canvas have very different goals and we were very reluctant to go the route of forking his work. We are always open to contribute changes back into Motion Canvas if that is wanted, so far we haven't seen that to be the case.

Thanks! We're using a server side ffmpeg process for the encoding right now, so running a server is required for rendering. We are exploring fully client-side rendering too but I'm hesitant to use WebCodecs because of the limited compatibility with many browsers. Ffmpeg-Wasm does look promising so I'll give that a closer look very soon. I'll also check out your project, thanks for sharing.

Hi Mokshith, we talked about releasing a project using the Sieve API and Revideo before! This is definitely something we still want to do. I'll reach out!

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

A more restrictive license ?

Remotion has a custom license that requires you to have a Company license if you don't meet certain criterias for the free license.

Revideo just has the MIT license.

Yes, exactly! We're also big fans of the generator function model. In Remotion, you get the current frame of the animation through a React hook called useCurrentFrame(). You then use React to build the UI based on the return value of the hook. By structuring it as a generator function, later parts of the function are for later parts of the animation, which makes it a bit easier to read and write. We found this to be a little more intuitive. Ultimately it probably comes down to personal preference.

Yes, that's us! We started out in the open source LLM space, but realized that most companies didn't really have any real use cases for custom fine-tuned LLMs. Maybe we were too early, but everyone we talked to was best served by just using OpenAI. Late last year, we started looking at other areas and became fascinated with AI-generated social media content, which sent us down a rabbit hole that led us to build Revideo. It's been a very long and painful process, but we now have a lot of really cool and smart users building really useful stuff, which is something we haven't experienced with any of our previous pivots.

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

We haven't played around with this yet but this is possible. There are people working on this stuff in the Motion Canvas community, which is the animation library we're based on. It should be pretty straight forward to adapt this for Revideo. https://github.com/motion-canvas/examples/tree/master/exampl...

Thank you! Love to hear it :)

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.

>> I've been using Shotstack's visual editor to create video templates but keep running into limitations

What limitations are you hitting?

What’s your functionality wishlist?

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

Thanks a lot! Really glad to hear this feedback :)

Encoding the video in the browser is on the roadmap, but currently we stream the frames one by one to an ffmpeg backend process and concatenate them into a video there. This has been very reliable and fast so far. I've only just started looking at WebCodec, but it seems to be more challenging, especially as most of the APIs aren't supported by some of the mainstream browsers, so as you said, some fallback will be necessary.

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.

Certainly! You can pretty much build full video editors with Revideo. There are many companies with video-editing at the core of their product that could have been built with us (think veed.io, invideo.io or the editor part of www.synthesia.io). We're thinking about building a template in this direction so people have a starting point when building these kinds of apps. In terms of video automation, we've seen people build apps for marketing and enterprise learning. One marketing tech company uses Revideo to generate video ads from their customers product catalogue.

So far, we only have a prebuilt Player component for React, but it is definitely possible to integrate Revideo into a Vue project with a bit of hacking. I'd love to better understand your requirements and help you get started. I already did this for React so porting this over to another framework like Vue should be straight forward - feel free to message me in our Discord server (invite link is in our repository) or email me at konsti at re.video.

The fact that it is JS actually implies more than just being written in a different language. You can ship Revideo as part of your website and run it inside the browser. One of the reasons we struggled with Moviepy was that we couldn't preview our changes in real-time which made the dev-experience a little tedious.

If you mean Moviepy, then yes, there are some advantages. As I mentioned in another comment, you can ship Revideo as part of your website and run it inside the browser. One of the reasons we struggled with Moviepy was that we couldn't preview our changes in real time which made the developer experience a bit tedious. We also like the syntax of our generator functions better, but that is of course subjective.

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)

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.

Thank you! Would love to hear your feedback when you give it a try :)

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

Hey! I'm not really familiar with either one so take this with a grain of salt. On the first glance, it doesn't seem like these projects are designed to be run in the browser. We're mainly focussing on the use-case of using Revideo as a part of web-apps (we're building on top of the HTML canvas API which makes it really easy to preview instantly). There might be some use-cases where a lower level implementation is more suitable.

Unfortunately not right now. Someone already created an issue for this though, so this is something we should definitely take a look at: https://github.com/redotvideo/revideo/issues/94

The main use case is not necessarily about AI, but about putting all sorts of assets together into a video. However, we definitely see a lot of people using AI-generated voices and images/videos for their videos, which we think is really cool. We will probably integrate these APIs more into Revideo in the future.

This is unfortunately not something that is currently on the roadmap. Revideo mainly runs inside the browser which is why we built it entirely in Typescript. You can check out moviepy (https://github.com/Zulko/moviepy) for a similar project written in Python.