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

Fri May 10 15:46:26 BST 2019

Hi Evert

Em sex, 10 de mai de 2019 às 02:30, Evert Vorster <evorster at gmail.com>
escreveu:

> Hey there, Harald.
>
> Harald, this last release is a massive one. As in, under the hood a LOT of
> things have changed. As a package maintainer for the kdenlive package in
> Arch I have been watching and tracking it for a while. (years) I was
> wondering when the devs were going to be brave enough to bite the bullet
> and call it stable. I commend them on their bravery, it's not an easy thing.
>

Well technically it is still a WIP but much more stable than the old code
base. BAsically if we didn't release we would never find all these issues
by ourselves in a short ammount of time. Hence why we will dedicate the
whole 19.04 cycle for polishing.

>
> The detail of your issue seems to be enough to have it resolved, but this
> forum is not a bug tracker. Which brings me to a problem in the kdenlive
> community.
> Through the years I have seen a few different bug trackers, and we seem to
> have the same problem with all of them. The bugs in them quickly multiply
> to the point where the devs feel overwhelmed and the reporters feel under
> appreciated. I myself have a few open bugs from 2016 that have not been
> addressed and that I am not happy about. I have been told that they would
> all be fixed with the new timeline code, which has just been released.
>

That was the problem with the old code base, it was all duct-taped and
became unmaintainable. For one to add a feature it would break something
else... now we have a lean and clear code, bug fixes and new features are
easier and faster to do. Eugen has done an incredible work in maintaining
the bug tracker, closing duplicates, testing reports, etc... we have closed
more than a 100 reports since the end of last year. There is still a long
road ahead but we are getting there.

Now, my bugs are more of the OCD type, and since I am not a heavy user of
> kdenlive anymore I will leave them alone while the devs hunt the bugs of
> guys like you that use it daily.
>
> My advice for you to keep your sanity... Use a previous version of
> Kdenlive as your daily driver.
> Occasionally check to see if the bugs that prevent you from using the
> latest release has been fixed.
>

Great advice, we have kept a legacy link in the download page to the latest
18.12 series appimage. We hope to fix everything until the 19.08 release
and then the cool new features will start rolling.

Cheers

>
> Peace
> Evert Vorster
> Awesome Chapters Tours
> http://www.awesomechapters.com
> Tel: +264 (0) 811477690
>
>
> On Thu, 9 May 2019 at 21:01, farid abdelnour <snd.noise at gmail.com> wrote:
>
>> Hi Harald
>>
>> Let me start by saying how much I think you are a valuable member to this
>> community (see the Toolbox among many other things) and I think the devs
>> feel the same. I just cannot but help to dislike your tone. Although I can
>> TOTALLY understand your frustration with seeing your daily driver not work.
>> Maybe because i follow the difficulties of develoipment on a day to day
>> basis...
>>
>> Em qua, 8 de mai de 2019 às 14:43, Harald Albrecht <
>> harald.albrecht at gmx.net> escreveu:
>>
>>> 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.
>>>
>>
>> We really tested as much as we could the code, but weren't able to catch
>> everything, this is why in the release notes we stated that we will focus
>> this whole 19.04 cycle to finish polishing things. Compositing somehow
>> broke during this code change, I didn't notice that during my tests, but as
>> far as I know JB already fixed it. Unfortunately I cannot give you a clue
>> as to why it happened, but it did and it is now fixed. The good thing now
>> is that fixing things is much quicker.
>>
>> 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.
>>>
>> During the process the focus was on stabilizing things. Now is the time
>> to focus of fixing stuff that broke during the code change, that is
>> probably why you might have gotten such answer (don't know really). About
>> the thing being "your fault" it was a community member trying to help out
>> as he couldn't reproduce your issue. I don't think the intention was to
>> blame you or to discredit you. It was in good faith.
>>
>>
>>> 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).
>>>
>> I really cannot tell when you felt a "get off my lawn" attitude, most of
>> the café yesterday was spent to hear your feedback and JBM fixed many
>> issues as you were reporting them.
>>
>> I here state for you and everyone reading that we are a community and not
>> a one person project. We value and want to listen feedback from everyone.
>> At least I hope you see this from the website posts, the cafés and
>> everything else...
>>
>>> 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.
>>>
>>
>> No one from the devs team feels that!
>>
>>> ***
>>>
>>> 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?
>>>
>>
>> I am sure the devs will fix everything you point to that is broken, I
>> just ask you to have (more) patience if things sometimes don't work. If you
>> have energy report themWe are gettng there!
>>
>>
>>> Harald
>>>
>>
>> Cheers :D
>>
>>
>> --
>> 1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة
>> fsf member #5439
>> usuario GNU/Linux #471966
>> |_|0|_|
>> |_|_|0|
>> |0|0|0|
>> <a href="http://www.gunga.com.br">gunga</a>
>> <a href="http://www.tempoecoarte.com.br">tempoecoarte</a>
>> <a href="http://www.atelier-labs.org">atelier-labs</a>
>> <a href="http://www.mocambos.net">rede mocambos</a>
>>
>

-- 
1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة
fsf member #5439
usuario GNU/Linux #471966
|_|0|_|
|_|_|0|
|0|0|0|
<a href="http://www.gunga.com.br">gunga</a>
<a href="http://www.tempoecoarte.com.br">tempoecoarte</a>
<a href="http://www.atelier-labs.org">atelier-labs</a>
<a href="http://www.mocambos.net">rede mocambos</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/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/20190510/5d950dfd/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/20190510/5d950dfd/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/20190510/5d950dfd/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/20190510/5d950dfd/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/20190510/5d950dfd/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/20190510/5d950dfd/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/20190510/5d950dfd/attachment-0013.png>