7 ms·
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 ver
by hkonsti 2y ago
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.
- supermatt 2y agoYou mention in your README that you had to fork it in order to make it so you could trigger renders programatically instead of having to click a button. Couldn't you have just used render from the core lib directly? https://motioncanvas.io/api/core/app/Renderer#render https://motioncanvas.io/api/core/app/Renderer#render
- justusm 2y agoYou 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 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/d0f72b6df68b380d751b4c44331eb311e113514a 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/a6e1bcdf0ca8200d646a3bca65122b50120f1013 https://github.com/redotvideo/revideo/commit/a6e1bcdf0ca8200...