This might seem a bit silly, but I want a clip to be sped up, until a certain frame, and then be frozen from then on. Unfortunately, it looks like the freeze effect does not take into account the effect that speed will have on the frame number it is supposed to freeze on. Reproducible: Always Steps to Reproduce: 1.Add second half of a 20minute clip to the timeline 2. Split clip on timeline in half 3. Speed up first half 5x 4. Speed up the second half 10x. 5. Add Freeze effect to second clip, and freeze the clip halfway through. 6. Drag around the slider in the freeze effect, and look at the frames displayed. Actual Results: Frames from the first half of the clip is displayed in the project monitor as you drag the slider around on the freeze effect. Expected Results: Freeze to actually freeze the frame I want.
Hmm.... I did a bit more searching on this. Take a long clip, and just stick the second half of it on the timeline. Apply freeze effect stopping the action about halfway through. This all works as expected. Remove freeze effect, and apply speed effect, 2x speedup should do it. Apply freeze effect again. Now, when scrolling over the clip, you see frames from the first half of the input clip, if not just the first frame on it's own. These are frames that were never put on the timeline, so it would appear that the freeze effect is confused by the speed effect, and then refers to the first frame of the source clip, rather than the frames exported by the speed effect. I hope this helps you in tracking down the bug. Not sure on how we will fix it, though. Looks like the motion effects operate at a lower level, and might need to produce a "virtual clip" that the effects lower in the stack it operate on, with fake starting and ending frames, numbered from 1 - end.. Kind regards, Evert
Still an issue. Applying both speed and freeze to a clip corrupts both effects. 2016-08-09
Cannot reproduce with recent 16.07.90 and MLT 6.2.0+. Freezing works when applied to a timewarped effect; freezing only applies to video though, but that should not be an issue, as I don't think freezing a single audio frame will be of much use...? Evert, can you please retest using recent Kdenlive beta and recent MLT?
Hi there. I have re-tested this error, and it is still quite apparent. I first noticed this error on some drone footage. The drone records from before takeoff until landing, and in one instance I used a piece of the clip from in-flight until landing. So, the second half of a clip. It was still quite long, so I decided to speed it up, but I wanted to freeze the last frame for a nice long fade-out. When applying the freeze effect over the speed effect, the first frame from the clip is displayed, not the first frame of the segment that I have selected, and no matter where I put the "freeze from" point, only the first frame of the clip is displayed. This leads me to think that the freeze effect is not aware of the speed effect. I can add a video clip of this in action, if you want?
Evert, imho a short textual description of the steps required to reproduce would suffice. I didn't tested with a timeline clip with in point other than 0, so that might be the reason I didn't noticed the bug.
This is still an issue with the freeze effect. I don't think it actually has anything to do with the speed effect. It looks like the freeze effect always starts from the first frame of the clip, rather than the first frame of the segment it is supposed to be working from. The freeze effect is also confused by just a normal segment of a clip that does not start at frame 0.
This is very old report. With the 21.03.70 (master) it works for me. Can you please test again and close this report if it is not relevant any longer?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!