| Summary: | git master 2016-06-17 - Speed and freeze effects do not work together.... | ||
|---|---|---|---|
| Product: | [Applications] kdenlive | Reporter: | Evert Vorster <evorster> |
| Component: | User Interface & Miscellaneous | Assignee: | Jean-Baptiste Mardelle <jb> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | fritzibaby, julius.kuenzel, wegwerf-1-2-3 |
| Priority: | NOR | Flags: | fritzibaby:
timeline_corruption+
|
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Evert Vorster
2016-06-17 18:13:21 UTC
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! |