SUMMARY When having at least 2 video tracks and using the Mix Clips transition between two clips from the same upper video track, the effect applies to the lower video track as well. STEPS TO REPRODUCE 1. Add a color clip on V1 track 2. Add two pictures/images on V2 track one after the other (the V1 track must be visible on the background) 3. Use Mix Clips to create a transition between the two. 4. Play the video and see that the color clip on V1 track also reacts to the transition instead of staying unchanged. OBSERVED RESULT The color clip on track V1 gets darker as the transition occurs and then it pops up again when transition ends. EXPECTED RESULT The color clip should not be affected by the transition. The transitions should only dissolve the two image clips from track V2. ADDITIONAL NOTES: The same applies if I use normal legacy compositions between tracks V2 and V3, which is not desired. SOFTWARE/OS VERSIONS Windows: Windows 11
Created attachment 150920 [details] project and files to reproduce issue
Thanks for your report! I can confirm this behavior following your steps. Something with track composition is wrong.
For anyone having the same issue or interested in fixing the bug, I have found a workaround: If you add an Alpha Operations effect to both images that are meant to use the MixClips effect, the desired transition is now possible without the black bars. Check out the workaround attachment. So the issue is definitely with the alpha and must be addressed in the MixClips effect itself.
Created attachment 157986 [details] Workaround with the desired behaviour
After finding out the the Alpha operations effect makes it work right, I tested out using png files with transparency instead of jpg files for the pictures. In this case the issue is no longer seen. It doesn't matter what is the size of the png file, it is only important to have an alpha layer. So, the fix for this issue should be something like, when using MixClips, it should automatically treat the images with a transparency layer even if the images do not have one.
Shotcut is already working on this. We may need to port the changes from there. See https://github.com/mltframework/shotcut/commit/6e5c57ef9edb06951cf972c4b5e1575f84265657
The commit in the MLT framework is this one: https://github.com/mltframework/mlt/commit/85d669e573d33ea7a786337a198e1c03620a1294
Anyone available to help porting the changes indicated from the Shotcut commit? I am not familiar with the Kdenlive codebase/repo.
Thanks a lot for your report and investigation. This will be fixed in git master and for the upcoming 23.08.0 version
Git commit d1178a66be64026c5e8b24f70b19d33a8684875c by Jean-Baptiste Mardelle. Committed on 13/07/2023 at 06:30. Pushed by mardelle into branch 'master'. Ensure luma transition considers padding as transparent M +6 -0 data/transitions/dissolve.xml M +3 -0 data/transitions/luma.xml https://invent.kde.org/multimedia/kdenlive/-/commit/d1178a66be64026c5e8b24f70b19d33a8684875c
Thanks for your time to commit this fix! I really appreciate it and can start working again on my projects without any workarounds. Confirmed fixed in nightly version 23.07.70 (rev. d2b889602)