Modify Input & Output Time Listings In Time Remap

Shotcut version 21.05.01

Currently in Time Remap the way that the Input & Output Times are listed are as milliseconds compared to the Time parameter that lists it as Unless I am missing something, I don’t see it useful to have the Input & Output Times listed as milliseconds.

Can they be made to be listed as like the Time parameter has it? That way it would be easily understood as to what each thing is referencing.

Great topic. I struggled with this…

The time parameter is hh:mm:ss:ff (frames), not

One reason that I use as the format in the input/output times is because that is what is displayed in the keyframes GUI. And that needs to remain because that is how it is stored in the underlying framework. I do not want to store frames in the underlying framework because then the project file would not survive changing the frame rate (we purposely always store time in the project file for this reason).

So I think we can break this into three topics:

1: What to show in the keyframes display? This necessarily needs to stay because that maps to the underlying framework.

2: What do show in the time parameter? This can be any format we want. So the options are:

  • hh:mm:ss:ff
    I originally chose hh:mm:ss:ff because I thought that would be more intuitive. But in reality, it actually limits the precision because it rounds off to the nearest frame in the project frame rate when in reality it could be much more precise. So this could be changes to or

3: What do show in the input/output status? I added these as so they would match what is shown in the keyframe display. And the Input status always matches the Time parameter. So it is really just a convenience conversion. I think there is enough horizontal space that we could probably fit two or three formats in there. So maybe we want to show something like: (

I would be interested in your opinion about these options and what is more intuitive.

If this can’t be changed then that’s that. :slightly_smiling_face:

Can the Input & Output Times also be any format we want? If so can an option be added then to both the Time parameter and the Input & Output Times for the user to pick the format similar to how the Time filter gives the user that option?

I would say any of these three:

  • hh:mm:ss:ff

The time filter gives the user an option for how the time will be displayed on the video. And each format is useful for a given use case.

These times are only shown in the UI. Generally, I prefer to consider the use cases carefully and pick on display format that is most appropriate for all/most use cases.

Right now, I am thinking about this:

  • Change Time parameter to display “”
  • Change Input & Output status to show both “” & “”

Do you think people would miss seeing the format that shows frames?

I am sure someone would, but that someone would not be me. :grinning:

Your idea of changing the Time parameter and Input & Output to show would create consistency. Adding both & to Input & Output is great too because then that would make it easy to tell what’s going on. They can look at the numbers listed in the keyframe timeline, see it match with Input & Output then see those numbers represented right alongside it as which they can then see also in the Time parameter. That essentially solves this. :+1:

The only thing is that while hh:mm:ss:ff may be the odd man out in the context of Time Remap it’s the format that’s seen in the counter under the player. So although our friend @kagsundaram wouldn’t miss it :slightly_smiling_face: I think it could confuse the average user because they are used to seeing frames being counted. Also, it’s less intimidating to type out in the Time parameter to add a keyframe. It’s much easier to remember frame 12 than millisecond 4379. Another thing is how will Decrement and Increment buttons work with milliseconds? You said that milliseconds are more accurate than counting frames but would pressing those buttons move them at the smallest millisecond number or just at the milliseconds that represent the next or prior frames anyway?

So can the Time parameter be the one place that has the option to either use hh:mm:ss:ff or


I agree that hh:mm:ss:ff provides consistency within the UI. Consistency is something I value.

The drawback is this: the hh:mm:ss:ff display can only be in the frame rate of the project. This is a technical limitation in the architecture that I have not solved. And in fact, it could be compounded in the future if someone stacks multiple time based filters. For example, imagine the time remap filter sitting on top of a frame doubling deinterlace filter.

However, for time remapping specifically, we encourage people to use higher frame rate sources to provide better frame precision for speed changes. They may be able to record in 120fps with their camera. Or they can upgrade the frame rate using the new frame interpolation in the conversion dialog. Either way, the current frame based parameter does not give them exact precision to select specific frames from their source.

Yes. That is a good point. Maybe it would still increment/decrement at the project frame rate (converted to seconds).

I think it has to be one or the other because they do not map directly. There could be a value in the .ms field that does not calculate to exactly one frame in the :ff field.

This is good discussion and I am not exactly sure what to do yet. But I lean slightly toward still.

Is that really a drawback? Once the frame rate of the project is defined what would it matter the in between milliseconds that are not being captured by the frame rate of the project? Are there plans for one day implementing an option to have the player counter have milliseconds instead of frames for more granular control of editing?

You know this issue is funny because one of my first requests here was asking if it was possible to have it that the counter under the player be configurable to go by “”. Dan said no. But now with Time Remap it’s like it’s preferable to go with “” instead. :smile:

By the way, one idea that I want to also suggest is adding a right click menu in the number field for the Time parameter that’ll just have two choices “Copy” and “Paste”. I know that there is already Ctrl+C and Ctrl+V that can be done in that field but left clicking in that field most times doesn’t select all of the numbers which makes sense because sometimes that’s not what someone wants. Right now with the counter under the player if you right click in there it selects all of the numbers while pulling up a menu. That’s what I mean that should be done with the Time parameter when right clicking. So when a user sees a frame that they like they don’t have to memorize anything. They can quickly right click in the field which will select all of the numbers and copy it. Then they can go wherever they want and right click again to quickly paste. It would help speed up workflow.

The in-between milliseconds are not captured by the project on a normal clip. But the time remap filter can reach those in-between frames when the speed is not 1.0.

No. That rule still stands at the project/player level. Just not the time remap filter.

I can see the benefit of that.

How can you seek those in between frames in Time Remap though if the left or right keys will move according to the frame rate of the project?

Cool. Can you also see it being added? :grin:

@brian I want to make another suggestion. It’s still related to this topic so I’ll keep it in the same thread.

You made the change back during the testing phases to make the Time Remap keyframe timeline be absolute so that the default start and end keyframes are mapped according to the whole source video. However, the actual time that is listed in the Time parameter is still going by the relative time of a split clip. This should be changed so the Time parameter is listing the absolute time of the whole source clip even if the filter has been applied on a split clip to go with the Time Remap filter keyframes taking the whole source video into account.

I think that could create confusing results. If you split a clip at a particular frame, you do it for a reason - that frame begins something interesting. If the time parameter were absolute for the source clip, then you could choose any time from the whole clip - including time before the split. So the split time would be meaningless. You could literally take a split at any arbitrary time because the time parameter would essentially override it.

I disagree. It’s confusing the way it is now.

But that’s exactly what you can do right now. In every other filter, time is mapped out horizontally. But in Time Remap you mapped time out vertically. That means it doesn’t matter where you split the clip you can still call on any moment in the source clip by creating a keyframe and scrolling it up and down. If that is how you want to design it then it only makes sense to then use absolute times.

This issue lays bare a big inconsistency in the way time is mapped out in this filter. Take a source clip with no B frames that is several minutes long, split a small section and add Time Remap to that small section. Without pressing the Zoom Keyframe Values button, add a new keyframe somewhere between the two default keyframes and bring it all the way up. It will hit one of the last frames of the entire source clip not the small section of the split clip. This means that that frame it hits will then be frozen for a while despite that not making sense since there is a slope and not a straight line in the keyframe graph.

Here are pictures to illustrate this.

Here is what the player shows for the frame of that newly added keyframe and the absolute time for it:

However, that exact frame is in a frozen state as it has been frozen earlier in the duration:

And it is still held frozen for several seconds after the point it was added on:

All this despite the fact that the keyframe graph shows a slope before and after the newly added keyframe which should mean a continual playback of frames. If it was actually frozen then the keyframe graph should show a straight line or a Hold keyframe. It doesn’t and that’s inconsistent. The reason it is frozen is because the time has been offset by the Time Remap filter mapping out the time relative to the split clip. If it was mapped out in absolute time then this wouldn’t happen.

1 Like

In every filter (including time remap) the output time is mapped out horizontally. Time remap maps the input time to the horizontal axis - but no other filter operates on the input time - so there is nothing to be inconsistent with.

OK. I see what you mean. I think the bug here is that the maximum value = “clip duration”, but it should be “clip duration - clip start offset”.

A workaround (or maybe a solution for you if you prefer it) is to never split a clip that you intend to use time remap on. Always apply time remap to a clip starting from the beginning. That will produce the behavior you desire.

I’m specifically referring to what you said here:

If the time parameter were absolute for the source clip, then you could choose any time from the whole clip - including time before the split.

The fact is you can choose any time from the whole clip regardless of where it’s split and how much is split as I demonstrated. And because you can do this but the time in the filter is always set relative to the split clip and not absolute then it will cause the issue that I showed in the pictures. You can run another test by applying Time Remap to the whole source clip (i.e. not a split clip), adding a new keyframe then bringing it up all the way to the highest point. You will see that the video will not freeze before the playhead crosses that new keyframe like it did in my example above. That’s because the time is not being offset by a relative time so the frames that the keyframes are marking are directly matching the time of the source clip.

It really only makes sense to use absolute times.

That isn’t practical.

You can not choose a time from before the split point because the lowest time value is zero and that maps to the first frame of the split. Timeremap does not allow specifying a negative input time which would be necessary to select a time before the split point.

I will take a look at the freezing problem you demonstrated. I believe the maximum value is not being calculated properly.

This is implemented for the 21.08 release.

I just tested the latest nightly build (21.06.30) and Time Remap is not showing up in the filters list.

I am fairly confident Time Remap is available. But if you open a project from a version created before 21.05, then Time Remap is not available for any existing clips - only newly added ones.

Nevermind, I just found a major regression in that nightly build that caused this as well. This has been fixed for 21.07.01