I can not think of a way because a keyframe does not have a speed. It has a time. We could make a default button to map the output time to the same input time. But the resulting speed would depend on the times of the keyframes before and after that point. Also, the “smooth” and “hold” keyframe types would complicate this. I’ll keep thinking about it.
This is true. But proxies already mask other issues. For example, the file date, or media properties that can be displayed with the Simple Text filter. I aspire to find a general solution so that proxies will not mask the original file.
The demo gif is restricted, unfortunately.
This is a good comment. I wonder if we should rename the filter. I am afraid that people will have a psychological association with the term “Time Remap” that is hard to break. And then they will have missed expectations. I also wonder if a different visualization would help. For example, we could show the input time and output times next to each other as additional status with an arrow pointing from input to output.
I really appreciate the feedback from everyone on this thread.
In the context of reverting to 1x speed, wouldn’t an easy(ish) solution be a button that alters the next keyframe (or end point if there is none) such that if three seconds exist between “current” and “next” keyframes on the timeline, then that next keyframe’s time value should be set to three seconds ahead of the current keyframe’s time value? This would reset the slope between them to 1:1 linear.
Ideally, this button would be used on the final keyframe after a slow-mo section to return to normal time. Although yes, it’s possible that if a speed-up was done instead, then there may not be enough clip remaining to fill the time. It would essentially end with a freeze frame in that case.
Yes. I reproduce this. The problem is not unique to timeremap. It also occurs on the gain filter for me and seems to be a general problem. I have been working on it, but I do not know if I will have a solution soon.
I did find a fix for this in Time Remap and Gain filters. If you notice other filters with the same problem, feel free to report them in a separate thread or on github.
@brian - Is this part of the same problem?
On the Gain filter, with Keyframes, the Keyframe view sometimes loses the audio waveform when the time magnification is increased.
The Gain filter in Keyframe view also sometimes loses the line between the Keyframe points on large video clips.
These are both sporadic events in 21.02.15, which I cannot reliably reproduce. It comes and goes mysteriously.
(Ubunu Linux 18.04, Kubuntu)
Thank you for your thorough testing and detailed reports. I think I have fixes for all the bugs you reported. I am still thinking about some of the usability concerns you have raised.
I have added two new buttons that the user can click to calculate a new value for the current frame to achieve a desired speed either before or after the current frame.
The “left” arrow button will open a dialog where the user can enter a desired speed and the time will be set to achieve the desired speed between the previous keyframe and the current frame. The “right” arrow button will open a dialog where the user can enter a desired speed and the time will be set to achieve the desired speed between the next keyframe and the current frame. Hopefully this will help to optimize the speed related use cases.
In regards to you saying that this filter is not meant for speed ramping, to compare I checked Adobe After Effects and it actually has a feature called Time Remapping and one its popular use cases is for speed ramping.
Just curious but is the B-frame issue a question of the technology not being available in order to handle it or just a lot of workload to handle it that would have to be done later?
After my first try, 2 weeks ago, I didn’t do other tests of the time remap filter. But tonight someone kinda pushed me back into it
I think I start to get the hang of it. Slowly. Took my a while to understand how to work with the 2 timers (Clip time and Output time).
I can pretty much slow a video where I want now and at the speed I want and also freeze it
Here’s what my last effort looks like.
It’s a 30 fps video… I suppose it would look better with 60fps videos.
I’ll try tomorrow. @Brian. Is it ok to give suggestions in this thread, or do you prefer to have only bug reports ?
Files with B-frames are inherently difficult to seek in because seeking requires finding the start of a GOP and then decoding all frames leading up to the frame of interest. Going forward is OK because the frame of interest is always the next frame. But going backwards is difficult because it involves re-decoding the same frames over and over from the beginning of the GOP. We can imagine algorithms to cache decoded frames to re-use them. But the underlying FFMpeg library that we use does not provide that. This inefficiency in seeking b-frames results in a very laggy experience that preview scaling can not help with.
The underlying FFMpeg library is not always frame accurate when seeking in files with B-frames. The accuracy is good when going forwards for the reasons I described in #1. But seeking backwards can result in unexpected results or un-smooth motion.
Here’s what’s throwing me off on the keyframe timeline. Even before any keyframes are added we start with a diagonal line (assuming it represents progression of time). I don’t think it needs to be diagonal since the cursor is also moving, so the movement represents the progression.
I would rather it start with a horizontal line (representing 1x speed). No keyframes added means it stays horizontal. You can even shade the area above the horizon as a different color to create a clear delineation between what’s faster and slower than 1x speed. Any keyframe added above the original horizon would represent 1< speed and below would be <1 speed. So a diagonal line going from low to high visually would also represent the speed going faster. It would also be somewhat on par with how Premiere and DaVinci visualizes their speed timeline. The line representing speed would be easier to understand than the line representing forward or backward.
In the example above, I slowed this 26;14 secs long clip two times and froze it one time.
The last keyframe was originally set at 26;14 by Shotcut, but to make the last section run at speed 1.00000x, I had to change this setting to 20;03. This results in losing about 6 seconds of the clip.
I suspect this is intentional, because keeping these 6 second would mean to make the clip longer in the timeline and would result in messing with other clips on the track.
But what if those 6 seconds of video are important ?
I know there would be ways to manually retrieve the missing frames from the original file and add them at the end, but that would be time consuming.
Is it possible for you to make the filter not erase those frames from the clip ?
If so, I suggest to add an option (a select box maybe) giving the user the choice of keeping or not the missing frames.
Something like this maybe:
Another suggestion would be to make the Time selection faster by giving separate controls for hours, minutes, seconds and frames. Hours isn’t critical I suppose, but to keep the layout homogenous… you know.
I also agree with @bentacular that a diagonal line is a bit confusing. I would prefer an horizontal line too, although I don’t see how a frozen part of the clip would be represented. Maybe a vertical line ?
Another suggestion
Would it be possible to give the user the choice of locking together the two last frames on the vertical axis?
Or some other way to insure that the last portion of the clip always stays at 1.00000x speed.
Frozen could be the ultimate slowdown speed. Let’s take the gain filter. It starts with a horizontal line. Mute is basically represented by a drop, all the way down to the base, which is volume = 0
The issue is @bentacular, your idea would be for a speed ramp feature. What @brian is doing is creating a filter that would also allow the ability to reverse the footage. That’s why he has the diagonal line representing normal forward time. And if you reverse the two starting keyframes by putting the first keyframe up and the last keyframe down, you reverse the footage.
Make the + and - buttons move a selected keyframe even if the playhead if not ON that keyframe. This would make it easy to see how the speed changes as we move the keyframe up or down:
As it is now, the + and - will add a new keyframe at the position of the playhead.
