V21.04 BETA/Unstable with Time Remap

[MusicalBox]

No. couldn’t reproduce it.
I think I followed your steps to the letter.

Bug report #1
https://icedrive.net/0/06WtY7BDGh

Bug report #3
https://icedrive.net/0/06SwtiLIzZ

[shotcut]

I added a Use sub-clip option (with rather descriptive tooltip) to the convert dialog for the next version.

I also added an Apple Silicon macOS build to the beta download page.

[MusicalBox]

Reporting this in case you’re not aware of it.
When importing images (tested with jpg and png) they don’t display correctly in the viewer.

https://icedrive.net/0/16YU1MTOMO

[shotcut]

@MusicalBox

When importing images (tested with jpg and png) they don’t display correctly in the viewer.

Noted, first time reported. This happens when you drag the image to timeline or playlist, not when drag to player or use File > Open.

[DRM]

@shotcut How long before this moves out of this beta and into the beta for the April release? I really haven’t had time to do much testing except for the couple of days I did last week.

[shotcut]

Maybe around April 10

[brian]

@MusicalBox

When importing images (tested with jpg and png) they don’t display correctly in the viewer.

Thanks for reporting this. It is fixed for the next release.

[brian]

@DRM

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.

I have been able to make a significant improvement to this for the next build.

[DRM]

@brian

Your steps seem very clear, and I can see the problem in your demo. But it does not happen for me when I test on Windows and Linux. When I try to set the speed on the last keyframe as shown in your video, the last keyframe does not change. “Not changing” is the expected behavior if there is no keyframe after it. Maybe there is one small detail that I am missing.

I have been very busy and haven’t really had much time to do as much testing as I wanted. As far as you saying that you can’t reproduce the bugs I reported, there really isn’t much more I can do on my end. I got some time today to retest my reported bugs this time on different clips and all of them happened again. Are you making sure you are selecting the keyframe by pressing the arrow button to seek to the next keyframe? Aside from that the only other way to see if you are repeating the steps I detailed is to record a video of you trying to reproduce the bugs.

@brian

Your demo brings an interesting question: If there are no keyframes after the current frame, should the filter create a keyframe at the end of the clip? Maybe users would be surprised that a keyframe was added at a position that is not the current position.

If the purpose is to get the desired speed selected but there is no keyframe to follow it then it would make sense to have a keyframe created to be able to set the desired speed. I think users would figure out that a keyframe would need to be set there in order to get the desired speed.

@brian

Yes. That was relating to the handling of keyframes when trimming the clip in and out. Please do some testing on that if you are able. In particular, observe what happens when you trim the in point or out point to go past a keyframe.

I’ll see if I have some time tomorrow for this.

@brian

I have been thinking about the blend mode, but have not made any changes.

Also, how about adding the Blend mode option in Properties if the speed is changed there?

@brian

I have been able to make a significant improvement to this for the next build.

That sounds great.

4) If you delete at least one of the default keyframes then create a new keyframe with the keyframe button and move that new keyframe while holding Ctrl, the keyframe will not be connected to the curve line. Demo.

5) If the filter is added to a split section of a larger clip, then the default last keyframe can be moved to the right past the length of the clip going as far as the screen and the source clip will allow. This seems to happen only with the default last keyframe and not the first. Demo.

[DRM]

@brian

Yes. That was relating to the handling of keyframes when trimming the clip in and out. Please do some testing on that if you are able. In particular, observe what happens when you trim the in point or out point to go past a keyframe. For the in point, the keyframe is “moved” to stay at the beginning of the clip (because there can not be keyframes at a negative position). For the out point, the keyframe stays at its position beyond the end of the clip. If you “untrim” the clip, the keyframes beyond the end of the clip are restored.

6) None of what you describe happens in this beta. The [ & ] buttons on the trackhead for the keyframe timeline don’t do anything. Pressing ] on the keyboard does not work. The only key that works is [ but the result is strange.

In this demo I first show that the [ & ] buttons on the keyframe timeline don’t do anything as I try to click on them. After that I place the playhead in the middle then I start to hit just the [ key on my keyboard and show how the default keyframes are moved around in a way that I don’t think is intended because it doesn’t make any sense. With the playhead in the middle of the two default keyframes, hitting the [ key brings the last keyframe closer to the playhead. But when I place the playhead beyond the last default keyframe then press the [ key it keeps sending the last keyframe toward the first default keyframe. Then when I bring the playhead before the first default keyframe and press the [ key the set of keyframes are sent towards the end of the clip. It comes across as buggy to me. I’ll also mention that after pressing the [ key the speed is affected only in random spots between being frozen to playing normally regardless of how close or far the default keyframes are to each other. To top it off, there is no visual indication of the trim handles in the keyframe timeline like there is for every filter.

And just to make clear, I am using version UNSTABLE-21.03.13.

[shotcut]

@DRM

The [ & ] buttons on the trackhead for the keyframe timeline don’t do anything. Pressing ] on the keyboard does not work.

This filter does not support filter trimming. He is talking about trimming the clip. We might have a bug where the corresponding keyboard shortcuts are not disabled in this case.

[DRM]

@shotcut

We might have a bug where the corresponding keyboard shortcuts are not disabled in this case.

It’d be a good idea to remove the and {} icons from the Time Remap keyframe timeline. If they are not used they just shouldn’t be there. In fact, since there are no simple keyframes or trim handles either then it’d be good to remove the top part of that keyframe timeline and only leave the Advanced Keyframe portion. That would make it clear that this filter’s keyframe options are not the same as all the others.

[shotcut]

@DRM

It’d be a good idea to remove the and {} icons from the Time Remap keyframe timeline.

They are disabled, and the toolbar is not unique to each filter. I think disabled is better. Some people do not like when things disappear and prefer them to be disabled because they do not want the location to move nor do they want a blank spot. I am leaving this the way it is.

That would make it clear that this filter’s keyframe options are not the same as all the others.

There are some other filters that do not support trimming (e.g. fade in or out) or simple keyframes.

[DRM]

Just so I know I got it right, @shotcut, there’s going to be another testing phase for Time Remap after this beta phase right?

[brian]

@DRM

4) If you delete at least one of the default keyframes then create a new keyframe with the keyframe button and move that new keyframe while holding Ctrl, the keyframe will not be connected to the curve line. Demo .

This is fixed for the next build

@DRM

5) If the filter is added to a split section of a larger clip, then the default last keyframe can be moved to the right past the length of the clip going as far as the screen and the source clip will allow. This seems to happen only with the default last keyframe and not the first. Demo .

This is by design, although, I admit that it looks confusing in your demo. The idea is that if someone had performed clip trimming (not filter trimming), they might not want some keyframes to be removed even though they are trimmed out of the clip because frames that are still in the clip might be interpolated from that keyframe. So I allow keyframes past the end of the dlip. The main problem with your demo is not that they place a keyframe outside of the clip, but that once they place it there, they can not manipulate it.

@DRM

Just so I know I got it right, @shotcut, there’s going to be another testing phase for Time Remap after this beta phase right?

We plan to make one last test build very soon.

[brian]

@DRM

5) If the filter is added to a split section of a larger clip, then the default last keyframe can be moved to the right past the length of the clip going as far as the screen and the source clip will allow. This seems to happen only with the default last keyframe and not the first. Demo .

I made some improvement to this. Before, the keyframe could be placed out to infinity. Now, it is limited by the duration of the clip - which might still be outside of the keyframe timeline, but it won’t be beyond the duration of the clip.

[DRM]

@brian, I think in the Alpha thread I asked something about what would happen if a clip is made longer or shorter after Time Remap is added. I think I suggested something about the lowest and highest points sort of updating dynamically to reflect the length being changed. I don’t know what your thought is in regards to that but in case I did bring that up before I want to say that after me giving it some more thought maybe it’s easier and more logical to just have it that when Time Remap is added to a clip the lowest point (i.e. the start frame) and the highest point (i.e. the last frame) are locked from that point on regardless if the clip is made longer or shorter. There could be perhaps a use case of someone using Time Remap just to make a clip run slower or faster as an alternative to the Speed parameter in Properties.

[brian]

@DRM

maybe it’s easier and more logical to just have it that when Time Remap is added to a clip the lowest point (i.e. the start frame) and the highest point (i.e. the last frame) are locked from that point on regardless if the clip is made longer or shorter.

I think we have a mix of this now. One constraint is that a keyframe can not be at a negative position. So, if the user trims in from the left any keyframe that would go negative is “moved” to stay at the zero position but with a value that is interpolated to that new zero frame position.

My goal was to minimize surprises to the user. If they have carefully selected input/output mappings, I do not want to break those mappings when they trim the clips from either end. So the result is:

• Make the clip longer from the start: The first keyframe does not move and the video will be frozen up to the first keyframe.
• Make the clip shorter from the start: The first keyframe will “move” to stay at position zero with a new interpolated value to maintain the frame mapping
• Make the clip longer from the end: If there are keyframes past the end of the clip, they may come into view. Else, the video will freeze after the last keyframe
• Make the clip shorter from the end: keyframes are allowed to fall past the end of the clip. They are not visible, but are still used for interpolation.

@DRM

There could be perhaps a use case of someone using Time Remap just to make a clip run slower or faster as an alternative to the Speed parameter in Properties.

Yes. I agree. And this is even more useful now that I have audio working better. But this is really easy to fix/change by clicking the “default” button on the time remap parameter to restore 1x speed and then use the new “set speed” buttons to set a single speed across the entire clip. So I do not think we need to optimize for this situation since it is so easy to change.