example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before

Fri Jun 14 12:45:22 BST 2019

On 08.05.19 19:42, Harald Albrecht wrote:
>
> This is totally frustrating as the new timeline doesn't allow the same 
> multitrack compositing as the old does. Things that worked for several 
> years in Kdenlive cannot be done anymore in 19.04. Nada. Don't work. 
> And this is not just an "import problem", it also happens when you 
> create the same project anew in 19.04. What reason is there to 
> completely change the track compositing mechanics during refactoring? 
> Please give me some clue why things get completely broken for what is 
> called the new "stable 19.04" Kdenlive.
>
Hello Harald, all

As several people already mentioned, the 19.04 release was a huge work 
and many things were far from perfect. However the release helped us get 
more feedback and we are fixing the problems as fast as possible

It is definitely on our roadmap to provide a reliable editing workflow. 
All compositing issues you reported in this mail are now fixed in git 
and available in the latest AppImage uploaded today:

https://files.kde.org/kdenlive/release/kdenlive-19.04.2e-x86_64.appimage.mirrorlist

Several different bugs triggered the problems you experienced. Sorry for 
that but as you know we are a small (but growing :)) team. Several UI 
performance improvements were also recently committed, so it should 
result in a smoother experience.

Hope the recent fixes will make it possible for you to continue and 
enjoy working with Kdenlive, don't hesitate to report issues.

Regards

Jean-Baptiste

> Alas, here's what is happing; project is attached. And no, this ain't 
> a superficial and artificial project to annoy devs. This is the 
> simplified and neutered version of what I was doing in many of my 
> daytime company-internal video projects. And I have to admit that 
> there's now almost no day where I don't seriously consider throwing 
> the towel and shelling out money for a commercial video editor for 
> Linux. It's not that I haven't raised several important issues during 
> the refactor branch with existing project. All I got was "oh, 
> importing existing projects isn't of any importance to us". Well, you 
> could have used that to quickly gather tons of real-world tests 
> instead of a small set of artifical unit tests. And to add more 
> insult, I get told during café that my Kubuntu disco OS setup "must be 
> special" when things break, so it's obviously my fault.
>
> I already experienced a rough transit during those days back of 0.9x 
> to 1.0/15.xx -- and I invested lot of patience as did JBM with losts 
> of real-world examples that broke during transition, the same bugs 
> getting squashed and returning multiple times during transit. So, I 
> understand how difficult such transits are. And I perfectly understand 
> JBM and the other devs to be done with such difficult and exhausting 
> transitions as a major refactoring. Been there, lived through that. 
> But there was a different attitude then.
>
> What, to my personal experience, is different this time is that I 
> experience more or less an attitude getting more and more bordering on 
> what feels to me like "get off my lawn". Not least reaching peak in 
> that ugly "importing existing project isn't of any importance yet" 
> some weeks ago when I raised my issues. Honestly, I don't feel any 
> need to file Kdenlive gitlab issues after that treatment even up to 
> the café. I know from my daytime job the importance to take user 
> feedback and bug reports very seriously, more so when refactoring a 
> product that worked sufficiently good for the existing user base 
> (notwithstanding that it needs refactoring nevertheless).
>
> Just for the record, I'm also doing development during my daytime, to 
> verify my architectural suggestions, so prototype novel ideas, and to 
> keep knowing what's like in a rapidly changing world of software. I'm 
> not talking ex cathedra, I leave that to others.
>
> ***
>
> This is the minified example of a typical track compositing I use very 
> often. Track compositing is set to "high quality". So, some video 
> "background" on V1 (to use new terminology). I then need to focus 
> viewers on a certain area in this background video by darkening the 
> unimportant parts in the video: using a full-frame gray matte on V2, 
> from which I cut out the region of visual focus using a "cutout title 
> clip" on V3. V3->V2 is composite&transform with "destination out".
>
> The V2->V1 composite&transform is just for a fade in with an alpha 
> ramp from 0% to 100%.
>
> Now, on top of this is some text with a title bar, on V5 and V4 
> respectively. V5 and V4 each get faded in with 0%->100%, and 
> composited onto V1, the bottommost background/video track. As you can 
> see here, this works as expected: the title and its bar slowly fade 
> in, and also the matte with its cutout also correctly fades in. Also, 
> at the end of the transitions for V5 and V4, the text and its title 
> bar correctly reach 100%. Keep this in mind for comparison with the 
> new refactored behavior.
>
> alpha 50%
>
> alpha 100%
>
> So, no rocket science here. Just plain multi-track compositing to get 
> things done.
>
> Head over to 19.04, same project loaded; but you achieve the same 
> results when you recreate from scratch. It doesn't look like an import 
> issue, and in fact I've found out when working on a fresh 19.04 
> project from scratch.
>
>
> alpha 50% ... seems to like fine on a first glimpse, but the 
> compositing is already different, so compare the last frame of the 
> fade in c&t.
>
> alpha 100% ... no, this doesn't make sense at all.
>
> First frame after the V4/V5 transitions ended: ... this is correct, so 
> the previous frame should have (almost) reached this.
>
> I've tried this on this day's kdenlive-19.04.1-dfe2c78-x86_64.appimage 
> <https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/kdenlive-19.04.1-dfe2c78-x86_64.appimage>.
>
> So why did you change multitrack timeline compositing? What compelling 
> reason is there to do so? And what sense does it make considering my 
> example showing that the explicit transitions behave totally different 
> from the implicit transitions, as opposed to behavior of the long-term 
> stable Kdenlive series?
>
> A stopgap measure is to throw in lots of unnecessary transitions to 
> basically override the implicit transitions almost everywhere. But 
> seriously, that cannot be a rationale for user experience for a 
> refactored product, can it?
>
> Harald
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bnfdgmkmphlpinlc.png
Type: image/png
Size: 33535 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kkhnlmafhidelmgh.png
Type: image/png
Size: 5538 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfpiknjpkigmkjpe.png
Type: image/png
Size: 5412 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgpabbbnjcnaofff.png
Type: image/png
Size: 45154 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdcehakombfedldb.png
Type: image/png
Size: 4381 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kojfbpgdjaoejjnb.png
Type: image/png
Size: 2321 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpadjfpjgpmiinma.png
Type: image/png
Size: 4460 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190614/56ee5292/attachment-0013.png>