Open JonnyBurger opened 8 months ago
Been messing with remotion for a short time so far (loving it! thank you!)
I may not have worked with it or react long enough, so take these ideas with a grain of salt.
durationInFrames
could just be frames
everywhere
seconds
could be added also if that was the intention of making the distinction <Sequence>
could work standalone and within <TransitionSeries>
and <Series>
<TransitionSeries>
could just be <Transition>
and <TransitionSeries.Transition>
could just be <Fade>
<Fade>
works within <Series>
and no need for <TransitionSeries>
export beforeRender()
inside a composition's component to colocate
calculateMetadata
etc<Sequence>
and <Series.Sequence>
have a component
prop like <Composition>
frame
and duration
could be passed to every Sequence children automatically
It would be cool to have something like camera movement so that the entire composition can be zoomed in and out, moved, rotate, etc. So for example you have a scene with a graph and a map next to it - show the whole composition first then zoom in on the graph, zoom out, move the camera slightly and zoom in on the map. Or another example - you have a map covering the entire composition - you can move around / zoom in and out or just rotate the entire composition slightly to create a cool effect. I often see it on youtube. @JonnyBurger
@dillingham Thanks for all the input!
durationInFrames
could just beframes
everywhereseconds
could be added also if that was the intention of making the distinction
I think frames
makes it easy to mistake for frame
. Also, the most important information is that it is the duration, right?
useVideoConfig() could be useSequence() so videoConfig means composition
I like this because indeed this hook returns just the data from the parent sequence, not from the video. Not sure about the name useSequence()
yet, but I'll add it to the list for now
<Sequence>
could work standalone and within<TransitionSeries>
and<Series>
- instead of
and
Those components have different props (like for example Series.Sequence has offset
additionally but not from
). This would make the types confusing if it was all just one element.
<TransitionSeries>
could just be<Transition>
and<TransitionSeries.Transition>
could just be<Fade>
- in a perfect world maybe
<Fade>
works within<Series>
and no need for<TransitionSeries>
- maybe it becomes part of core
We choose the names explicitly. TransitionSeries is for transitioning between scenes, it is not just a "Transition" (actually the Transition is a child of a TransitionSeries), so the rename would be confusing.
TransitionSeries.Transition
allows for all kind of presentations, like slide, so "Fade" is also not an accurate name for this component.
- maybe there could be
export beforeRender()
inside a composition's component to colocate- instead of putting api requests in
calculateMetadata
etc
You can colocate the calculateMetadata() function next to your component! But to automatically recognize it in a file implies a file-system-based router like in Next.js and that there is just one composition per file, which is not the case.
Right now we don't offer this to eliminate as much magic as possible, but I like making a file-system based composition register in the future as opt-in.
- maybe
<Sequence>
and<Series.Sequence>
have acomponent
prop like<Composition>
- maybe useful and cleaner if you just want to render out some scenes without props
If you then end up deciding to add props or refs, you will ned to refactor it back to <Sequence><Component {...props}/></Sequence>
which is not terribly verbose in my opinion (actually less characters to type!)
- maybe
frame
andduration
could be passed to every Sequence children automatically- useCurrentFrame() seems almost like a constant in any component
- and would maybe avoid making the shift of what seems like global functions to sequence scope
- (referring to when currentFrame starts at 0 in a sequence even though current frame may be 2000
For React developers, it's unintuitive if props get automatically added to a component. TypeScript would also not pick that up automatically, and you would have to give it a special type annotation for it to recognize that it has additional props, which takes more typing not much easier than just using the useCurrentFrame() hook.
Also, it will make the component re-render on every frame, but not all components need the frame! It is wasteful to make it mandatory for every component
- maybe some magic to automatically determine the total durationInFrames for calculateMetadata
- doing the math to figure out transition overlap and dynamic sets of sequences kinda was interesting
- would be smooth if each of those components reached up somehow and told the main composition their frames
Discussed here: https://www.remotion.dev/docs/miscellaneous/automatic-duration
Sorry to smash most of these feature requests.
One of the guiding principles of Remotion is to make all APIs explicit and remove as much magic as possible, and I think those ideas are aligned with the design ideas of React.
The time saved with "magic" often gets lost again because a special behavior was unintentionally introduced, which then leads to increased support from our side.
For syntactic sugar that is not contrary to these priciples, I am always open though!
It would be cool to have something like camera movement so that the entire composition can be zoomed in and out, moved, rotate, etc. So for example you have a scene with a graph and a map next to it - show the whole composition first then zoom in on the graph, zoom out, move the camera slightly and zoom in on the map. Or another example - you have a map covering the entire composition - you can move around / zoom in and out or just rotate the entire composition slightly to create a cool effect. I often see it on youtube. @JonnyBurger
In the Remotion Studio, you can already zoom and pan the canvas. Or do you mean to add these effects into the video? In this case, you would just achieve it with Transforms. I don't think any of these improvements need to be a breaking change though.
What I mean is to be able to add animations such as in this video - https://www.youtube.com/watch?v=8pbz2H7UTwQ from around 1:12 - rotation, zooming of the entire canvas. I'll check out if this can be done with transformations, as suggested.
Finally - I think one ground breaking feature would be to be able to render locally. I know youve been looking into that and currently it cant be done using Web workers - although there have been some updates to support native languages recently.
Wouldnt it be possible to render locally using something like html2canvas and then stitching the images together ? (https://www.npmjs.com/package/html2canvas) ? I'm using this library to create thumbnails of the composition and it works fine. @JonnyBurger
@reactone You can make these animations for sure using transforms! For rendering in the browser, the blockers are explained here https://www.remotion.dev/docs/miscellaneous/render-in-browser
That makes sense - I didnt realise that html2canvas has its limitations. Im quite surprised there is no robust way of converting an html element to an image. I was thinking about coding my own, but then it would take ages probably as every css property would have to be mapped.
Anyway, one feature Im looking for is also to be able to animate (move) elements along a path. There is now a css motion path module ( https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_motion_path) . Whats the best way to achieve this in remotion - is there a package that helps with that or it would have to be custom coded? I know there is remotion/paths but it doesnt seem to be related to animations. Maybe worth to include in v5 @JonnyBurger
@reactone The best way is indeed to use our paths package, this API specifically: https://www.remotion.dev/docs/paths/get-point-at-length
Subtract the initial point to get the offset to apply to your element. You can also use getTangentAtLength() to rotate the path
Please add ability to fit in
Speed up / slow down if needed
Its essential for creating dynamic screencasts from desktop capture
@brianconnoly No breaking change for this is needed
Plus <Player>
+ <OffthreadVideo>
both already have a playbackRate option, so you can speed up either an individual video or the entire thing
It is a chance for us to fix bad API decisions (and fix flaws in our licensing + raise awareness of our license)
visualizeAudio()
should switch tooptimizeFor: "speed"
by defaultselectComposition()
andgetCompositions()
should requireinputProps
(footgun)getTangentLength()
andgetPointAtLength()
should return null if length is bigger than the path lengthuseVideoConfig()
touseSequence()
validateFontIsLoaded
by default totrue
for layout utilsbundle()
signature - return type maybe should not just be a string?openBrowser()
should just acceptlogLevel
instead ofdumpIo
<Series>
should be made a<Sequence>
itself--disable-headless
build
folderiReadTheLicenseOnRemotionDevLicense
prop for the Playerfrom
andto
valuesoverwrite
option should be true -> Allows to skip the checktsconfig.json
default - "moduleResolution: 'bundler' " (From CodeHike)pauseWhenBuffering
totrue
by default