I did not make any changes to the blend logic.
Thereâs a problem with proxies. In 21.03.21 if I drag a clip to the playlist and then click on its properties, it shows resolution â640x360 (PROXY)â. I can drag it to the timeline and click properties there, and says the same thing. If I close then reopen the project, both remain the same.
However, if I do the same in 21.04.14 (on Windows, or 21.04.13 on Ubuntu, also UNSTABLE-21.03.13 and UNSTABLE-21.02.09) the first part is okay, but when I reopen the project now both the playlist and timeline clips have resolution â1920x1080â. And if I drag the playlist clip to make another clip on the timeline, that one now says resolution â1920x1080 (PROXY)â. If I split the clip that says â1920x1080 (PROXY)â, then the first half of it changes to â640x360 (PROXY)â while the second half stays â1920x1080 (PROXY)â, and if I turn off preview scaling the resolutions are indeed the blurry 640x360 versus the crisp 1920x1080.
Obviously, this makes it rather impractical to work on high-resolution projects, since itâs using the original files rather than the proxies.
Well, actually thereâs problems in 21.03.21 too. If you change the speed of a clip after reopening the project, sometimes itâll change to â1920x1080 (PROXY)â rather than â640x360 (PROXY)â.
For example, put a clip on the timeline and change its speed property. Save then reload the project. Change the speed again, and now notice that it says proxy at the wrong resolution.
This is fixed for the next version.
in 21.03.21 too. If you change the speed of a clip after reopening the project, sometimes itâll change to â1920x1080 (PROXY)â rather than â640x360 (PROXY)â.
Update: this is also fixed for the next version.
I found some time to do some testing.
1) The âUse sub-clipâ option is not working as expected. When the clip is replaced, the converted sub-clip does not start on the frame that the original sub-clip started on. It starts the sub-clip from somewhere else in the source footage.
2) After making a sub-clip I donât get extra footage on both sides. I get 30 extra seconds from the right side only. I suggested bumping the extra footage up on both sides from 15 seconds to 30 in the previous beta thread for Time Remap so I donât know if this is the result of that.
3) I donât think the âUse sub-clipâ option should be in the Advanced Menu. Itâs going to be a very commonly used option so itâs better to have it quickly accessible. Moving it up to the normal menu would be preferable so as to not have it sort of hidden. Alternatively, but I donât know if it can be programmed this way, the âUse sub-clipâ can be automatically turned on by Shotcut depending on where the option is called. If itâs called from the whole clip then it would be off but if itâs called from a sub-clip then the sub-clip option would be turned on by default.
4) When the sub-clip option is used the default name for the converted file still adds âConvertedâ at the end just like it does if it was converting the whole source clip. I suggest making the default file name different if itâs converting just a sub-clip. Maybe something like âSub-1â? I am thinking of a use case where users would be applying Time Remap more than once on the same source file in one project. If that is the case, is it possible that Shotcut can be programmed to have the default names number down the subsequent sub-clips in one project? Like Sub-1, Sub-2, Sub-3, etcâŚ
5) There are some video files that are bypassing the B-frames dialog after applying Time Remap. Here is one: The Bruno Mars video from youtube âLeave The Door Openâ. Here is the direct youtube link.
When it itâs applied, this is how the key frames are laid out by default:
Suffice it to say, despite the filter being added the keyframing just doesnât work.
For what itâs worth, here are the video and meta data info for the mkv file I downloaded off of youtube:
Iâll get more some time later on to do some more testing.
That link takes me to youtube. Can you provide a link to a file I can download?
Are you SURE the video has b-frames? I have found other VP9 files in the past that do not have b-frames. The Shotcut properties panel does not report if the file is encoded with b-frames.
I downloaded it, and it does not according to Properties > More Information (ffprobe):
has_b_frames=0
Also, Keyframes is OK for me after adding Time Remap (I am using development version)
This is fixed for the release.
3) I donât think the âUse sub-clipâ option should be in the Advanced Menu. Itâs going to be a very commonly used option
It is advanced in that most beginners or casual users will be confused about the concept of a sub-clip, however, I also agree it may be frequently used by many. One way to remedy this is to not make Advanced collapsed/hidden but to show it all under the heading Advanced.
can be automatically turned on by Shotcut depending on where the option is called
It is harmless to turn it on for a whole clip, but it does affect the scope of the subsequent replace operation. With sub-clip on, it replaces only the selected clip, and without it replaces every timeline clip based on the original source. I will think about this more, but it might be tricky to add because of the disparate code components and how this same dialog is triggered for multiple situations.
Ok. So this is working correctly. Besides the âMore Informationâ, there is not an easy way for a user to know that a file does or does not have keyframes. Maybe something to improve in the future.
Same for me.
@DRM I wonder if there is something unique about your environment or installation that keyframes are not working properly. You had some similar reports in the last beta that I could not reproduce. Do you have access to another computer you could test these same cases on?
Well, I learn something everyday. 
I didnât expect that youtube uploads were done with no b-frames.
However, in regards to the keyframes I shouldâve been more specific. @shotcut, you added Time Remap to the whole clip for that picture you took. When I did my picture to show how low the default last default keyframe was, it was on a split clip. In this new version, it seems that the way the keyframes are now mapped is absolute and not relative to the sub-clips.
Here is how the default keyframes are mapped to a split section of the video from the beta version of the Time Remap:
Those keyframes are relative to the sub-clip with the last default keyframe being at the highest point which is the last frame of the sub-clip.
But here is what happens with the exact same split section of the video in this version:
The default last keyframe is lower and when I was trying out it seems that in this version the keyframes are mapped out to sub-clips in an absolute way. So the last default keyframe is lower because thatâs where that frame is found if the keyframes were added to the whole source clip. I donât think this was intentional because this doesnât make it very usable to keyframe if the default keyframes are not mapped out relative to the sub-clips. What if the source clip is a 2 hour video but the sub-clip is 30 seconds?
Also, @brian, I think that the placement of the Input and Output times should be on a separate column. So instead of this:
it should be like this:
That way the Input and Output times donât get so easily cutoff when the Filters panel is made smaller.
Later I am going to try again with this version the bugs in the beta that you said couldnât reproduce. Hopefully itâs not something regarding a Windows update. I made a report almost 2 months ago regarding the layouts being screwed up every time when I open Shotcut but @shotcut said he couldnât reproduce it either.
Nothing about the keyframe mapping changed between the two versions that you show. What did change is the âscaleâ of the y-axis of the keyframe display. If you look at the first image you provided (from 21.03.13), what would you do if you want to set the speed to 2x? You can not drag the right keyframe up because it is already at the top. For this latest version, I scale the y-axis to the entire clip so that you have the option to drag it up or down for the entire duration of the original clip.
Your attention to detail amazes me.
If you want to make the 30 second clip play at 1.1x speed, then the display will be inconvenient. If you want it to play at 100x speed, then it will be very convenient. So there is a tradeoff right now. Maybe someday in the future we will add some vertical zoom feature to the keyframe display.
I agree that results in less vertical space. But it does not conform to our UI guidelines to always put the label on the left and the value on the right.
I also considered combining them somehow. For example:
Map: 16.6416s -> 16.6416s
But I was not sure if that would be intuitive
Thanks.
Right so itâs absolute now and not relative. I donât think this is a good idea because like I said if the source footage is very long then how can the keyframes be done on a small section thatâs just mere seconds? The relative scaling was better. Hereâs another use case that is now very hard to do in this new version: Reversing footage. Previously if you wanted to reverse the footage all you had to do was take the first default keyframe and raise it to the highest point and take last default keyframe and bring it all the way down. Now how can the user measure those points easily?
On the previous beta version while holding Alt down, you would bring the last default keyframe closer to the first keyframe until the Speed counter tells you itâs at 2.00000x speed.
Iâll call back my suggestion from the beta thread here:
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.
My thinking here is to keep the keyframes relative to the clip/sub-clip that Time Remap is added on. If someone wanted to use a frame that is from later on in the source clip then they would have to add Time Remap to split clip that has that frame. Then if they wanted to speed it up they would bring that keyframe in closer to the start of the clip. Then they could split the end off at where the keyframe has been reset and there is the desired effect.
That makes more sense and is much more usable than the absolute method that is being done now.
I want to also take back what I suggested in that above quote. Time Remap cannot really be used as a true alternative to the Speed Parameter. There are use cases that the Speed Parameter is much better suited for.
On another note, @shotcut one suggestion I want to make that really should be added for the upcoming release is to communicate to the user that Ctrl and Alt lock down the keyframe movement vertically and horizontally. This is sort of hidden because the only way to know this other than by finding out accidentally is to look at the keyboard shortcuts and many donât do that. For the Size, Position & Rotate filter you added that note the comes up:
You should do something similar to all of the filters that have keyframes with curves including Time Remap. When the advanced keyframe button is pressed a note should come up saying something like âHolding Ctrl locks keyframe vertically, Holding Atl locks keyframe horizontallyâ. The way Time Remap is done here makes the use of Ctrl and Alt a must and the user needs to be made aware. But I wonder if the placement for this note should be somewhere different than the one for Size, Position & Rotate because the users eyes may be away from the player when turning on advanced keyframes.
Also, I think the color for these kinds of notes should be something else other than blue. Blue is the color that is used to note use of Proxy and Preview Scaling so when that new note for the filter comes up users miss it because it blends in with the note for Proxy and Preview Scaling. Notes should be a different color like maybe green.
For the next build I have added a toggle button to allow the user to scale the keyframes to fit within the vertical space. Essentially, this button toggles between the current behavior and the previous behavior.
This button is available for all filters that have numerical keyframes.
I think a future improvement will need to be adding values to the vertical axis for min, middle and max values. I will have to think about where this would fit.
I would recommend using the buttons for setting speed (they accept negative values for reverse). That would be much more precise than dragging keyframes. But now you can hit the toggle button to scale the values if you prefer.
@shotcut, would you consider extended the end date for this version by a few days? I didnât really get a chance to test this as much as I wanted to as Iâve been busy.
Here are issues I found with version 21.04.26.
6) Keyframes donât work after the Zoom In Keyframe button is pressed with any filter (e.g. Brightness, Gain/Volume, Opacity, Size, Position & Rotate, etcâŚ) outside of Time Remap. Once the button is pressed no values are being changed despite the keyframes being moved around. Also, when the Zoom In Keyframe button is pressed and you move a keyframe while holding down the Ctrl button, the keyframe is separated from the curve line. Demo.
7) The help dialog for keyframes with curves about Ctrl and Alt doesnât appear for Time Remap.
8) When you press the Zoom In Keyframe button then click away to another filter, another clip or another layout and come back to it, the button is turned off.
9) While the newly added suggested file name for Exporting Frames does come up, after pressing Enter or Save no file is exported.
10) With the modification of the suggested file name to make the export of frames quicker, why not simplify the shortcut for Exporting Frame? Ctrl+Shift+E is a little hard to grab. How about either just E or Shift+E which are easier to grab and would help make the process even quicker?
11) The âDo not show this message anymoreâ should be removed for the Convert dialog. If users click that then they wonât be able to use Time Remap.
12) Setting the input time button to 1.00000 doesnât work even if clip is stretched out past last default keyframe. Demo.
This hasnât been addressed and in the latest version the sub-clip option is still hidden.
7) The help dialog for keyframes with curves about Ctrl and Alt doesnât appear for Time Remap.
OK, I just added that.
9) While the newly added suggested file name for Exporting Frames does come up, after pressing Enter or Save no file is exported.
This was a problem on Windows build; fixed.
10) âŚthe shortcut for Exporting Frame? Ctrl+Shift+E is a little hard to grab.
I do not want to change this at this time. Certainly not any more difficult than Ctrl+Shift+S.
11) The âDo not show this message anymoreâ should be removed for the Convert dialog. If users click that then they wonât be able to use Time Remap.
fixed
This hasnât been addressed and in the latest version the sub-clip option is still hidden.
I did it a different way: I added a checkbox in the Advanced section to keep Advanced open - similar behavior to Export Advanced.
This is because you only have one keyframe. So the zoom range maximum and minimum are the same. The graph behaves badly in this case. The timeremap filter would also do this if you delete all but one keyframe.
I have made the following changes to improve this:
- Do not allow dragging when zoomed to one keyframe
- Show min, mid and max keyfame values in the graph
- When zoomed to one keyframe, only show the mid value
- When zoomed to one keyframe, always place the keyframe in the middle
of the y axis
The zoom button zooms the graph to fit the largest and smallest keyframe values. Some people will request a variable zoom. I am not going to implement that for this release.
This is on purpose so that when people leave and return to the filter they arenât confused because they have forgotten that they left the zoom on. Many people will complain about this. But those complaints will be less noise than all the people who would otherwise request support because they accidentally left the zoom engaged and forgot.
This just occurred to me. With the Reverse option, if you select the whole clip then use Reverse it reverses the whole clip. If you use Reverse on a sub-clip it reverses just the sub-clip without the need of an option to check.
Can Convert be programmed just like this? That way it skips the whole need for a sub-clip check box at all and just converts what was selected be it the whole clip or a sub-clip whether the user manually selects Convert from properties or its called on by Time Remap. It would simplify everything and make the most sense.
No, as I explained, the sub-clip option also affects the scope of the following replace action. In the case of Reverse, you very rarely want to replace every clip from the same source. However, in Convert you frequently do. With sub-clip only the selected clip is replaced; without sub-clip each clip from the same source is replaced with the conversion result.