Bug 371729

Summary: git master - Transitions are affected by clips' alpha channel, though it shouldn't be [video included].
Product: [Applications] kdenlive Reporter: Unknown <null>
Component: Video Effects & TransitionsAssignee: Vincent PINON <vpinon>
Status: RESOLVED INTENTIONAL    
Severity: normal CC: null, wegwerf-1-2-3
Priority: NOR    
Version First Reported In: git-master   
Target Milestone: ---   
Platform: Other   
OS: Linux   
URL: https://youtu.be/KIwP-2ZWoQw
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Unknown 2016-10-26 23:54:48 UTC 
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
Comment 1 Wegwerf 2016-10-27 19:56:42 UTC 
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.
Comment 2 Wegwerf 2016-10-27 20:01:11 UTC 
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).
Comment 3 Unknown 2016-10-27 20:20:32 UTC 
@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.
Comment 4 Wegwerf 2016-10-27 20:33:55 UTC 
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.
Comment 5 Unknown 2016-10-27 22:53:52 UTC 
You got it buddy. Closing bug and opening a topic in Phabricator. :)