V21.04 ALPHA/UNSTABLE - Time Remap

Good catch. I fixed this.

This was a very good clue for me. In order for the time remap filter to work, we have to open clips in a special way. I think I have all the places that we open a clip fixed now to use the new open method.

I also fixed this. The time remap should never appear in the video category.

Unfortunately no, even though some people may wish that the filter operated on speed rather than time. The speed parameter is only a status that is calculated in real time.

I do not reproduce this. It changes with both for me. But maybe in one test you were not making a change that affected the playhead. Remember, the speed status is a real-time status that is reporting the speed of the currently viewed frame.

Unfortunately, you keep running into the opening bugs. From my testing, the only reliable way to get the time remap to work in this alpha build is to use the File->Open method to open an already converted file. I have fixed that problem for the next build.

For the shape of your keyframes, you would have seen the clip go forward quickly, then reverse quickly, and then forward at approximately normal speed for the rest of the clip.

1 Like

Then is there a way to have a sort of a default button for the speed that can revert a keyframe to 1.00000x speed?

1 Like

Yes! That fixed it. Thanks @brian
I have all the filters lists now, and the filter open normaly.

time_remap_filter-lists

It will take a few tries to learn how to use Time Remap efficiently, but for now, I can fast forward, rewind and freeze frame.
Cool !

I certainly understand the concern.

As noted earlier, all-intra proxies can mask this issue. Could an exception or warning note be made for people willing to remap on proxies, then be content with however slow the final export is?

My concern is that I can easily see the forum filling up with “why won’t my video remap” questions. The fix could be very convoluted to explain, and time- and space-intensive for the user to convert clips at high quality, much more so than saying “turn on proxies and try again”. My concern is that the user experience of reaching out to the forum for help could be worse than message-boxing them to use proxy mode.

Just a thought.

Here’s a demo. I move the key frame first with Alt. Look up where it says “Speed” that is above “Direction”. The speed numbers don’t update as I use Alt. Then I move the keyframe with Ctrl and you’ll see that this time it does update. Then I move with with Alt one more time and like before it does not update as the keyframe is being moved around.

What would take longer to do? Sort out the B frame limitation or write a Speed Ramp filter (i.e. it only affects speed going forward)?

I ask this because even though you point out that Time Remap is not meant for speed ramping that is what most people will take it as and try to use it for. Speed ramp has been such a high demand that people will see “Time Remap” as Shotcut’s name for speed ramping. And that’s where the limitation of the B frame issue will rear its ugly head. I can see people being frustrated that they want to do speed ramping but they have go through the hoops of having to convert their file whereas with proprietary software they don’t.

Time Remap is a very interesting feature and I am more than happy to continue testing it so it can grow more and more. But I think the technology you developed here would be best shown off first with a filter that works just as instant as all the other filters currently in Shotcut. If the shorter path to that would be to make a Speed Ramp filter then I think it’s really worth considering.

This will be in the documentation. I do not want another warning dialog. People do not need a warning dialog that something they have to already wait considerable time for will be a little longer. Following that logic, there are many filters and situations that would warrant a similar dialog, and too many dialogs drags down the user experience.

We are not in a competition. We will continue to deliver something that falls short of expectations and state-of-the-art. This is what we do: make something and share it with others. Given your logic, we would work on something and probably never share it.

I must have misunderstood. My interpretation was that Time Remap in its current form would work on All-I proxies, but then throw an intentional error when flipping back to originals that have B-frames. This would effectively prevent a full-res export despite seeing a successful proxy preview. Does it work differently than this? I was looking for a workaround if an intentional “no B-frames” rule was in place.

No, not intentional, simply a seeking problem masked by the proxy. We definitley have it with the state of AVCHD in the latest version without Time Remap. We have probably have it on other things often in more subtle ways. In context of Time Remap, I do not yet know the extent of it; it is too early. Definitely the performance impact on the preview user experience is more visceral. One can approximate it today by encoding a clip with a GOP that is a few seconds but with no B frames. Honestly, B frames only slightly exacerbate the problem, but it was much easier to detect and signal up the software stack than P frames.

1 Like

Wow! This is great! Maybe some of the pre-processing required could be automated in a Job, but even with functionality like this … :star_struck:

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.

3 Likes

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.

Very useful for precision work too.

Strange. How about now?

@brian, can you see the the gif that I reposted in my post just above?

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.

1 Like

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

I do not think so. I think that those are both related to the inefficiency of drawing the timeline/keyframe displays with large files.

1 Like

This is fixed.

This is fixed.

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.

1 Like

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

2 Likes