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

Wed May 8 18:42:47 BST 2019

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.

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/20190508/01fbb3c1/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/20190508/01fbb3c1/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/20190508/01fbb3c1/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/20190508/01fbb3c1/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/20190508/01fbb3c1/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/20190508/01fbb3c1/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/20190508/01fbb3c1/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/20190508/01fbb3c1/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: track-compositing-test-old-stable.kdenlive
Type: application/x-kdenlive
Size: 15630 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0001.bin>