How to reproduce: - Load the attached project (including Arrow.png which will be attached in the next comment) - Notice how the blue arrow is cropped *and* displaced between 00:01,00 and 00:04,00, but not anywhere else - Notice how the cropping between 00:01,00 and 00:02,00 appears to match the dimensions of the orange arrow (which is unscaled, and automatically zoomed by kdenlive to fit the project size) - Notice how wrapping the arrow in a title clip as shown between 00:05,00 and 00:09,00 prevents this unwanted cropping / displacement. It's possible that I'm misunderstanding something, but this cropping and displacement of the blue arrow looks like a bug to me.
Created attachment 114374 [details] kdenlive project reproducing the issue
Created attachment 114375 [details] arrow image as a .png file
This is interesting. I download your project incl. the arrow. By loading it into Kdenlive Windows version 18.04.1d Kdenive makes a backup because of some newer version. Played the timeline and then Kdenlive crashes. In the event viewer I see that module msvcrt.dll generated the crash. Then I checked your Kdelive project file. Why you have MLT 6.10.0 installed? This is not compatible to your version. Please download the latest AppImage (maybe version 18.04.1) and try again.
Thanks a lot for the reply! However I tried with the latest 18.04.1 AppImage and the problem is exactly the same. Regarding your other question, I originally installed kdenlive and its dependencies from the Packman openSUSE repositories, and if kdenlive 18.04.3 is not compatible with MLT 6.10.0 then that is a bug in the way these packages are packaged - check out line 74 of: https://pmbs.links2linux.org/package/view_file/Essentials/kdenlive/kdenlive.spec?expand=1 It only specifies a lower bound for MLT, not an upper bound, and currently the repository has MLT 6.10.0: https://pmbs.links2linux.org/package/show/Essentials/libmlt Is this upper bound documented anywhere? It's not mentioned at https://community.kde.org/Kdenlive/Development Thanks again!
I’m not a developer of Kdenlive. I just see that in some cases the code has to be adapted for MLT: https://phabricator.kde.org/R158:9b09dbb2b0de78d4eaf4011c8a462fdb3c6916b6. And this leads me to say stay with the AppImage. Could you redo the project again with the AppImage to see if you still get the crash? Don’t use the existing Kdenlive project because I assume the bug is “built in” now.
fritzibaby@gmx.net wrote: > I’m not a developer of Kdenlive. I just see that in some cases the code has to be adapted for MLT: https://phabricator.kde.org/R158:9b09dbb2b0de78d4eaf4011c8a462fdb3c6916b6. And this leads me to say stay with the AppImage. Sure - I can understand the advantages of staying with the AppImage, but why did you say that MLT 6.10.0 isn't compatible with kdenlive 18.04.3? > Could you redo the project again with the AppImage to see if you still get the crash? I never got a crash from this. That's not the problem I reported. > Don’t use the existing Kdenlive project because I assume the bug is “built in” now. Hrm, that sounds unlikely to me but I can try if I get time.
(In reply to Adam Spiers from comment #6) > fritzibaby@gmx.net wrote: > > Could you redo the project again with the AppImage to see if you still get the crash? > > I never got a crash from this. That's not the problem I reported. > > > Don’t use the existing Kdenlive project because I assume the bug is “built in” now. > > Hrm, that sounds unlikely to me but I can try if I get time. I tried with a brand new project, and the behaviour was exactly the same. However on further experimentation I discovered that: 1. The lower composition with the background colour clip is irrelevant to the test case, and could be removed. 2. The weird behaviour vanishes when I edit the Composite transition and deselect the Align checkbox. 3. Leaving the Align checkbox checked and unchecking the Fill checkbox results in even weirder behaviour whereby the blue arrow gets significantly scaled down. 4. Using an Affine or Composite and Transform transition instead of Composite results in equally weird behaviour where the blue arrow gets scaled up. 5. Composing with a colour clip exhibits the same behaviour as composing with Arrow.png 6. Composing with an empty track causes the problem to vanish I suspect at least some of this behaviour is the result of the png being 810x300 whereas the project is 1920x1080. This would seem to be corroborated by the fact that wrapping the arrow in a title clip (which would have the effect of making its dimensions match the project's) eliminates the weird behaviour. I'm more convinced than ever that this is a real bug.
I can also confirm that scaling the arrow to the project size externally (e.g. in Gimp) is another valid workaround, on top of the empty track trick mentioned in comment #7.
Had a similar issue last week with a picture that size was smaller than the project settings (I.E: 1080p) by using an Affine or Composite and Transform transition. After I put onto the timeline in a picture that size matches the project setting everting works fine. Workaround: make sure all clips and picture matches the project settings size before you put it on the timeline. Make the picture of the arrow as big as your project settings are and work with an alpha channel to hide not needed picture area. I think a pop-up warning would be good or the question if Kdenlive should re-size the picture/clip according the project settings.