https://bugs.kde.org/show_bug.cgi?id=368681

            Bug ID: 368681
           Summary: git master 2016-09-12:Applying speed effect causes
                    corruption in fades
           Product: kdenlive
           Version: unspecified
          Platform: Compiled Sources
                OS: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: NOR
         Component: User Interface
          Assignee: j...@kdenlive.org
          Reporter: evert.vors...@yandex.com

I have this rather long project in which I am mixing 30fps and 25fps footage. 
I have decided to slow down the 30fps footage by 83% so that I do not get the
pulldown effect. 
The actual wanted speed is 83.333333333%, but there is no way of specifying
that. 

Unfortunately, the many issues with the speed effect strikes again. 

Reproducible: Always

Steps to Reproduce:
1. Put several 30fps clips in a 25fps project
2. Apply fade to black on them 
3. Apply 83% speed effect
4. Shrink clips to original timespan
5. Play back the video

Actual Results:  
It now appears as if there are "extra" fades on the video clips, where the clip
would fade to black in the middle. 
I automatically split out my audio. One can't resize the video part of a clip
unless ungrouped from the audio. 
Un-grouping keyboard shortcut does not always work.

Expected Results:  
Keyboard commands to be applied consistently
Speed effect to be applied to audio and video (seperate bug files for this one)
Fades to be where they are visually represented in the clip

The implementation of the speed effect needs to be re-thought. In it's current
form it completely breaks the user experience of kdenlive. 
Kdenlive has been quite stable as of late, and the many open issues with the
speed effect is negating all the hard work. 

In my mind the speed effect should not even be an effect, it should be a clip
job, the same as stabilize et. al. 
There is no reason not to have it both as a clip job and as a effect.
The reverse clip clip job already does what we need, all that is needed is to
be able to set the speedup/slowdown when the .mlt is created. 
One last niggle... there is no way of cleanly specifying 30/25 slowdown in
percentages, resulting in a dropped frame every 100 frames.. Annoying.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to