example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
Patrick Rogers
patrickrogers at national.shitposting.agency
Thu May 9 22:55:38 BST 2019
I think that you would have a better time getting responses from people
if you didn't act so entitled and antagonistic.
>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.
And yet you come to this mailing list asking for help? Do you even want
answers? lol
>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.
If you're such a smart 600 IQ genius programmer, why didn't you fix this
problem yourself and contribute to the program?
On 2019-05-09 3:06 p.m., harald.albrecht wrote:
> I notice that my reason for speaking up is unfortunately not getting
> through, and that is, in my opinion, due to solely focusing on the
> developers refactoring task and the primary goal of stability, where
> stability has different semantica for devs and for different users. As a
> user I value stability across releases, that functions work as learnt
> and used. Of course, values differ.
>
> Any tonal issues are easily solved now, as I stop stepping forward here
> or engaging again, raising issues and asking for reason why things get
> changed. My need for a NLVE is as described and this doesn't seem to be
> Kdenlive's roadmap. That's fine, so let's end this here. There's no
> common understanding and no sign that it might happen, no pun. It's your
> community.
>
> Harald.
>
>
> -------- Ursprüngliche Nachricht --------
> Von: farid abdelnour <snd.noise at gmail.com>
> Datum: 09.05.19 21:00 (GMT+01:00)
> An: Kdenlive <kdenlive at kde.org>
> Betreff: Re: example project: 19.04 Multitrack compositing still broken:
> differs from all previous Kdenlive versions back to 15 and before
>
> 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 <mailto: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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patrickrogers.vcf
Type: text/x-vcard
Size: 357 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/a065232f/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/a065232f/attachment.sig>
More information about the kdenlive
mailing list