User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build Identifier: 16.11.70 See video in URL field for complete example & details. In short, the transitions in Kdenlive produce unexpected results and behavior because they're affected by the alpha channel of video clips, Title clips, etc. Reproducible: Always Steps to Reproduce: 1. Insert a video clip in timelime, then insert a Title clip over it, then add a third video clip that starts at the end of the other two, overlapping the others a bit. 2. Apply a wipe transition between them. 3. Playback timeline. Actual Results: The transition is affected by the alpha channel of the clip and produces unexpected results, forcing a more complicated edit to compensate than should be necessary. Expected Results: For the transitions to behave consistently independent of the alpha channel of title clips, video clips, etc. Bug discovered while using Kdenlive 16.11.70 git master build via ppa:kdenlive/kdenlive-master. Ubuntu 16.10, Unity 7.5.0 desktop environment. KDE Frameworks 5.26.0 Qt 5.6.1
Erm, but my understanding is that this is exactly the way MLT and transitions work in Kdenlive. While it may not be exactly top user friendly I don't see any bug here. There's a reason why I'm blogging about transitions and transpareny a lot, because that's a more complex topic than what probably most people would expect.
Argh, forgot to ment6that a wipe is the same as a composite transition. Now you may have seen my recent toolbox post about transitions and transparency ... that's because the wipe/composite takes the alpha channels of both upper and lower track frames into consideration, and then the time-dependent opacity parameter. A wipe has simply implicit start and end keyframes, with 0% and 100% (or the other way round, depending on direction/reverse).
@Wegerf, I see your point, though other editors make this much easier to accomplish in fewer steps and less headache. I can change this to a wishlist/request-for-improvement bug if you feel it's more appropriate.
How could this be made better in concrete steps? This is probably better maintained as a Phabricator item, to reduce the bug report load. The main issue at hand is that MLT is architected as a service network, not as a track engine. I don't see how we can change the situation without a complete rewrite of MLT and its transitions. So a Phabricator item will be better for brainstorming.
You got it buddy. Closing bug and opening a topic in Phabricator. :)