Hello @brian
I’m wondering if making gradual speed changes is on the road map.
Using the Smooth keyframe type doesn’t quite work because the line curves bellow 1.00000x and makes the video go to reverse for a brief moment.
1 Like
It can help to not make every keyframe type smooth to gain more control over the curvature. In your smooth example, to prevent the portion between keyframes 2 and 3 from going into reverse, change keyframe 2 to linear. Then, it will still curve into and out of that portion. See also
I’ve tried every configurations.
It seems to work when I set only the third keyframe (from slow speed to normal speed) to smooth.
If I set only the second keyframe (from normal speed to slow speed) to smooth, it makes the video go briefly to reverse.
I’m not reporting a bug. I’m just wondering if there will be a way to make gradual speed transition in the Time Remap filter.
Re-read my message. I updated it while you were typing. The type of keyframe before a line segment controls its interpolation.
I think you should be able to do it now. I suggest to try adding a couple of intermediate smooth keyframes between the two in order to coerce the line the way you want and avoid the line going past zero.
Sorry to both of you if I often look like the dumb student in the classroom. My poor excuse is the trouble I have sometimes to clearly translate in English what I try to say.
Using the actual keyframe type settings to make smooth speed transition might work, but finding the right way to set the keyframes will be different each time. Depending on if you speed up, slow down or freeze the video, it will involve each time some amount of tries and guesses.
My video above was just an example to illustrate what I meant with my original question. I’ve tried a lot of ways to make it work, and I will try even more based on your suggestions.
So for now I guess the answer to my question is: The only way to make smooth speed changes is using the Keyframe type settings, and nothing else is planed as an alternative way.
Thank you 
Correct.
But if you find a scenario that can not work well with this, then we should explore it further to see if we can improve it.
Based on UNSTABLE-21.02.25
6) The speed is not starting at 1.00000 now. It starts at a speed past it. With this clip it’s starting at 1.00028x:
images2.imgbox.com/4c/a5/sdtZJ8aB_o.png
7) I’ve experienced the same thing that @MusicalBox is reporting with the Smooth keyframe. The behavior of it has to be looked at because it’s too erratic to the point of being useless as it’s so unreliable. This doesn’t happen on other keyframes with curves. I’m expecting a smoother transition between two speed points but sometimes it just decides to reverse footage and go forward again and there is nothing on the curves to show that it’s doing that. To reproduce this right after adding the Time Remap filter add three keyframes that are about 4 seconds apart from each other. Do not alter the time or speed on any of them. Just add those three keyframes. Then change the second of those three keyframes to smooth. When you play it back and it gets closer to that second keyframe you will see it reverse for no reason even though no change to speed or time was applied. Here is a demo.
Notice in the demo you can see the aforementioned issue of the speed not defaulting to 1.00000 as the clip has the speed at 1.00018x as its default.
8) Simply adding the Time Remap filter adds crackling sounds to the audio. This can be heard in the demo I just linked to above.
9) I’m not sure what the filter trim buttons are doing now but they behave strange. If I put the playhead right in the middle of the default start and end keyframes and press the left filter trim button then I press the reset button in the time parameter, even if it looks like the start keyframe is at its default position it’s actually frozen. So it ends up that the first half is frozen.
10) Cutting off the start and end of a clip with I or O makes the keyframe timeline end up looking like this:
images2.imgbox.com/8e/81/zyX2QJpk_o.png
11) If you take a clip with the Time Remap applied then strech the end of the clip out to make it longer the result is that the last keyframe is held there as a freeze like this:
images2.imgbox.com/32/e1/x1RHamtN_o.png
Likewise if you strech out the start of the clip then the first keyframe also is held as a freeze like this:
images2.imgbox.com/30/17/DQwEl2iJ_o.png
I think what would be better is that after the strech all the keyframes get their heights dynamically updated to match the time since the frames that have been marked on the keyframes would not be in the same height as per the time depending on the strech. If someone is using this filter decides after setting some keyframes to then make the clip longer because they want to grab a frame from earlier or later to apply to their keyframes with the current way its set they would have to reset the whole keyframe timeline and redo everything.
12) It seems that adding Time Remap alters the colors/tint on a clip.
Frame without Time Remap:
images2.imgbox.com/0a/3e/SXPVHvrZ_o.png
Frame with Time Remap:
images2.imgbox.com/0a/59/MUZVZhII_o.png
The blues in the sky are darker in the original frame without Time Remap.
13) Since you are going to go ahead and debut this filter even with the B frame issue I think that there should be an additional option added to the Convert To Edit Friendly feature. Right now Convert to Edit Friendly converts the entire source file. Most use cases for Time Remap are not going to be using the entire source file especially if a video with a long duration being used. It’s usually just one section or a couple of sections that are used from a longer video. So how about a new added option that gives the user the ability to just use Convert to Edit Friendly on only a selected section instead of converting the whole source file similar to how the Reverse feature only reverses a selected section? So on Convert to Edit Friendly the user can get to pick between two options: Convert the whole source file or convert only the selected section.
With that in mind in order to avoid the big hoop of having to do Source > trim > Export > intermediate or lossless preset > Export File > double-click completed job to do only a selected section, how about when you pick the the Time Remap filter and the dialog comes up instead of it just telling the user that the clip is not compatible and that they have to go ahead and do every step themselves to convert the section they want, that dialog would ask the user if they want to convert the clip to use the filter. When they say yes then they are taking to the Convert to Edit Friendly option to convert just that selected section.
If this filter is going to go ahead anyway then I think that this is the best way to avoid having to go through all the previous suggested steps to get a compatible clip going. However, the one limitation to this is that once this clip is converted what is in the timeline now is limited to just the start and end of the newly converted clip. Since it’s not coming from the source file this means that if the user during their use of Time Remap wants to stretch the clip more on either side or both sides to have more footage to work with they won’t be able to do it. I’m wondering if some kind of an additional option can be created to give the user the chance of going back to the original source file of that selected section to pull more footage from it and convert that to a new file to replace the last Convert to Edit Friendly selected section.
14) When the Blend option is picked in Image Mode it applies it regardless if the footage is going faster, at regular speed or slow. Can there be an option added to only apply Blend if the footage is going faster or slower than 1.00000x?
By the way, could the Blend option be added to Properties near the Speed parameter?
1 Like
@Brian we will have to disable smooth keyframes on this filter. It is impossible to change the interpolation algorithm to avoid these unexpected scenarios.
I was designing in a different venue some time back, I I ran into the same problem using cubic curves.
In that case, I found the by swapping which thing I called “x” and which I called “y”, flipping the cubic equation on it side, as it were, I still got a smooth cubic curve between the two central points of my four points, albeit a somewhat different curve, but dy/dx then never went from positive to negative (or vice versa) within that range, neither did “y” ever exceed the high/low range of the two center points.
Sorry but that does not help much. If you want to add a new interpolation algorithm and figure out how to serialize and deserialize in a unique but compatible manner, then you need to make a code contribution to MLT. It also should be able to transition between yours, linear, and discreet/hold like the current one does.
1 Like
I suspected it might not fit the application at hand, but I thought possibly it might; which is why I framed it as “this worked for me”, trying as best I could to avoid implying “you should…”.
Good catch. This is fixed now.
The reason that this occurs is because for smooth keyframes Shotcut tries to fit a line for the smooth keyframe, the two keyframes before it, and the two keyframes after it. In your demo, the “2nd keyframe after” is all the way at the end of a long clip. You can “fix” your same example by adding one more keyframe one second after the last keyframe. By doing that, you can “coerce” the line fit to be more subtle and it will not try to go backwards. I agree that this might be unexpected or counter-intuitive for users. I do not like applications where there is a “trick to it”. But it is also a lot of work to implement a new curve fit algorithm. I hope that with this additional explanation some people can experiment further and we can brainstorm ways to make it more intuitive without throwing away what we have. Give it a try, and let me know what you experience.
I experience this sometimes, too. It has not been a priority for me to investigate. I think it might occur more often when the clip sampling frequency does not match the playback sampling frequency (48,000). If you have some time to experiment with sampling frequencies, let me know if you find any correlation.
I have a work-in-progress to improve this. Hopefully it will be available to test in a week. I will be interested in your feedback.
I believe this has been existing behavior for some time and can be seen when using other filters. I do not plan to address it in the next couple of months.
This will be part of the work-in-progress that I have.
Fixed. thanks.
I think this is a good idea in general. I do not plan to do this right away. But we should consider it for an improvement after the time remap has been released.
Great idea. This is done.
I have to admit that the blend mode is very crude. I believe that we occasionally see frames blended when the speed is 1.0000x due to rounding errors. I think that instead of adding an option, I just need to make the blend mode match people’s expectations.
- For 1.0x, there should be no blending as you suggest.
- For <1.0x, it should blend between two frames proportional to the distance between the two frames of the ideal time. For example, if the mapped time calculates to frame 1.25, then it should blend frame 1 at 75% and frame 2 at 25%.
I will keep this in mind and look for a good opportunity to improve the blending logic.
I hope it doesn’t come to that. Much of the power of the time remap effect is the ability to smoothly change the speed. I think we just need to find good ways to make the keframe UI intuitive for people in these complicated scenarios. Somehow they need to know to add more keyframes to coerce the curve to fit their desires.
2 Likes
This looks like it is based on cubic equations.
(If it is not, ignore all that follows.)
Yes.
But how hard is it in software to tweak the end conditions before applying the algorithm? Can the software add the “one more Keyframe” as a phantom at each end, and then snip it off after the algorithm has done the hard math?
There is still the problem of knowing where to put the phantom point to avoid the undershoot.
Call your last three points Kn-3, Kn-1, Kn, and your phantom point K’.
Looking at how a cubic fits to points, any time you have a sharp descent from Kn-2 to Kn-1, then flat or a shallow descent from Kn-1 to Kn, the cubic will undershoot. However, if the slope and distance of Kn to K’ is made the same as the slope and distance as kn-2 to Kn-1, the point Kn-1 is forced to be the bottom of a curve, and there will be no undershoot between Kn-1 and K’, as you are getting now.
Of course, the phantom point K’ will be deep in undershoot territory, but that is “past the end”, and you are not using that; it only serves to fix the Kn-1 to Kn without changing the algorithm itself.
1 Like
For other filters, the curve is not a big problem as long as the filter correctly handles values out-of-range. We recently found this problem with opacity and fixed it. Time Remap is special because it strongly couples direction with speed making it too easy to get unexpected results than can be difficult to see and understand simply by the curved line. Even our power users here have expressed confusion. Limiting to linear does not break the ability to smoothly change the speed. Humans do not see speed changes easily, and the addition of 1 or 2 linear key frames ought to be good enough. I volunteer to work on the change.
It is a Catmull-Rom spline. Here is where it chooses points:
and
Bear in mind that changing this in any way changes existing behavior of all smooth keyframes of all parameters of all filters of all existing projects. Yes, we sometimes make breaking changes but try not to and sometimes need to make hard decisions. We went through a lot of that in 2020. Now, we already face another difficult one with a non-backward-compatible project file format change with this code branch. The decision to make here is not hard because there is a simple resolution: It must be added as new.
1 Like
Agree wholeheartedly.
I recently had a Size, Pozition, Rotate animation PNG overlay that had an abrupt “jerk” between linear Keyframes; I easily fixed it with a few transition linear Keyframes.
This thread is closing for the new beta thread; however, I want to mention that I think this is a good idea and the option can be added for Convert in general. I will attempt to add that for the release candidate. Like Reverse, it will also add up to 15 seconds of additional footage before and after to facilitate transitions and revising edits. Currently, when a convert job completes it replaces the source of all matching clips in the project. When this option is turned on, it will not do that and only replace the currently selected one.
Please go to the beta version thread now