From elhoir at gmail.com  Wed Jul  4 21:58:12 2018
From: elhoir at gmail.com (=?UTF-8?Q?Javier_Agust=C3=ACn_Fern=C3=A0ndez_Arroyo?=)
Date: Wed, 4 Jul 2018 23:58:12 +0200
Subject: Beware of FFMPEG 4 and MLT 6.8
In-Reply-To: <CAHMxv36nX2kaxQgkaLdm4TtHoiK69QbnBRBGhC6PCAyBwom-Fw@mail.gmail.com>
References: <CAHMxv36nX2kaxQgkaLdm4TtHoiK69QbnBRBGhC6PCAyBwom-Fw@mail.gmail.com>
Message-ID: <CAAHf8rfyYUM8KNF3H7jFN3BcZ2oh3NhSTJj-Xvaa6wEixsvhUg@mail.gmail.com>

hello,

I guess ffmpeg 4.0.1 doesnt work too, but...
What about new MLT 6.10 ?

On Wed, May 16, 2018 at 4:18 PM, farid abdelnour <snd.noise at gmail.com>
wrote:

> Do not use FFMPEG 4 and MLT 6.8 since they break Kdenlive's
> functionalities.
>
> I have already reported this to Archlinux packagers. If your distribution
> has those versions please inform us or report it to them.
>
> Thanks
>
> --
> 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/20180704/d1b49a2c/attachment.html>

From snd.noise at gmail.com  Thu Jul  5 22:57:17 2018
From: snd.noise at gmail.com (farid abdelnour)
Date: Thu, 5 Jul 2018 19:57:17 -0300
Subject: The future is almost here
Message-ID: <CAHMxv34eqW5fUkT0oi6EEE+-AFNfmo-XOxcq8AtwTrOFr0Z+KQ@mail.gmail.com>

Please help test the latest refactoring beta version. More info here:

https://kdenlive.org/en/2018/07/kdenlive-test-the-future/

An important step for Kdenlive and the community's involvement is very
important at this point.

Cheers <3

-- 
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/20180705/92823542/attachment.html>

From informatica at actiu.net  Fri Jul  6 08:43:29 2018
From: informatica at actiu.net (Narcis Garcia)
Date: Fri, 6 Jul 2018 10:43:29 +0200
Subject: The future is almost here
In-Reply-To: <CAHMxv34eqW5fUkT0oi6EEE+-AFNfmo-XOxcq8AtwTrOFr0Z+KQ@mail.gmail.com>
Message-ID: <06b2cdc9-fbce-4369-c3ac-609344b8d891@actiu.net>

"Most of the code was rewritten, which also means many possible..."

I say: Some Kdenlive users need LTS versions instead of needing to be
trying latest AppImages forever.

Issues found in this kdenlive-18.08-beta17-x86_64 :

1. tested a clean DVD/PAL project: Add an MP4 to project {Audio AAC,
video H.264, clip monitor plays perfect}. When trying to drop in
timeline (first track, with label "V3"), action is prevented with a
message "No available audio track for split operation".
I suppost default project timeline should have well-ordered tracks:
V1,V2,A1,A2 and there should be a preferences option to not use new
separation feature.

2. Proxy clip seems to be only generated manually (not due to
preferences enablement).

3. Cut scissors seem to work only as a "direc tool"; no "cut clip"
action with context menu to cut on cursor position (I know there is a
main menu bar option).

4. File -> Open : Can't open folders with non-english characters in
their names (double-click and no effect).

5. Default folter to save projects should not be "Documents" but
"Videos" in user profile.

6. Theme and style switch process is a bit inconsistent, but there are
very good results with AppImage!

7. Is there som way to convert a project to be fully portable? I mean,
to Kdenlive gathers all related files and copies/moves them to a
selected folder (a project's one).
+ What is the: Project -> Archive project ?


Congratulations for reached stability this time.



El 06/07/18 a les 00:57, farid abdelnour ha escrit:
> Please help test the latest refactoring beta version. More info here:
> 
> https://kdenlive.org/en/2018/07/kdenlive-test-the-future/
> 
> An important step for Kdenlive and the community's involvement is very
> important at this point.
> 
> Cheers <3
> 
> -- 
> 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>

From jb at kdenlive.org  Fri Jul  6 15:35:59 2018
From: jb at kdenlive.org (Jean-Baptiste Mardelle)
Date: Fri, 6 Jul 2018 16:35:59 +0200
Subject: The future is almost here
In-Reply-To: <06b2cdc9-fbce-4369-c3ac-609344b8d891@actiu.net>
References: <06b2cdc9-fbce-4369-c3ac-609344b8d891@actiu.net>
Message-ID: <73934900-04cb-bbf7-97e9-f5b93a025e25@kdenlive.org>


On 06.07.2018 10:43, Narcis Garcia wrote:
> "Most of the code was rewritten, which also means many possible..."
>
> I say: Some Kdenlive users need LTS versions instead of needing to be
> trying latest AppImages forever.

For sure. But for that we need to reach stability. That's what we hope 
to achieve with the 18.08 release.

> Issues found in this kdenlive-18.08-beta17-x86_64 :
>
> 1. tested a clean DVD/PAL project: Add an MP4 to project {Audio AAC,
> video H.264, clip monitor plays perfect}. When trying to drop in
> timeline (first track, with label "V3"), action is prevented with a
> message "No available audio track for split operation".
> I suppost default project timeline should have well-ordered tracks:
> V1,V2,A1,A2 and there should be a preferences option to not use new
> separation feature.

Done, 2 audio tracks and 2 video tracks by default now.
Disabling the automatic separation will not be possible anymore. However 
I also find it annoying to have that issue. Maybe we can find a way to 
make it more flexible, we need to think about it. For example insert 
video only if no audio track is available, or add icons that allow to 
drag only audio part or only video part from the bin or monitor.
> 2. Proxy clip seems to be only generated manually (not due to
> preferences enablement).
Fixed in git now
> 3. Cut scissors seem to work only as a "direc tool"; no "cut clip"
> action with context menu to cut on cursor position (I know there is a
> main menu bar option).
There is a "cut" entry in the timeline clip context menu to cut a clip 
at razor position (It didn't work I just fixed it)
> 4. File -> Open : Can't open folders with non-english characters in
> their names (double-click and no effect).

I cannot reproduce. Will do more tests. You mean you have a project file 
stored in a folder with non standard characters and cannot access the 
content of the folder from the file > open dialog ? Can you copy/paste 
the name of the problematic folder in a mail?
>
> 5. Default folter to save projects should not be "Documents" but
> "Videos" in user profile.

Fixed in git
>
> 6. Theme and style switch process is a bit inconsistent, but there are
> very good results with AppImage!
Nice. I did some improvments to limit the annoying "Restart kdenlive 
message" appearing when not necessary.

> 7. Is there som way to convert a project to be fully portable? I mean,
> to Kdenlive gathers all related files and copies/moves them to a
> selected folder (a project's one).
> + What is the: Project -> Archive project ?

Currently the easiest way to achieve this is to have all clips stored in 
subfolders of where the project file is stored. The "Project > Archive" 
function was designed to move all used clips in such a folder hierarchy 
but needs to be ported because of all the refactoring changes.
> Congratulations for reached stability this time.

Thanks.
I will upload a new AppImage on sunday with all these fixes for more 
testing.
>
>
>
> El 06/07/18 a les 00:57, farid abdelnour ha escrit:
>> Please help test the latest refactoring beta version. More info here:
>>
>> https://kdenlive.org/en/2018/07/kdenlive-test-the-future/
>>
>> An important step for Kdenlive and the community's involvement is very
>> important at this point.
>>
>> Cheers <3
>>
>> -- 
>> 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>


From informatica at actiu.net  Fri Jul  6 17:14:45 2018
From: informatica at actiu.net (Narcis Garcia)
Date: Fri, 6 Jul 2018 18:14:45 +0200
Subject: The future is almost here
In-Reply-To: <73934900-04cb-bbf7-97e9-f5b93a025e25@kdenlive.org>
Message-ID: <13ca7597-239d-6b8f-8ae0-e36b6ea8e49f@actiu.net>

El 06/07/18 a les 16:35, Jean-Baptiste Mardelle ha escrit:
> 
> On 06.07.2018 10:43, Narcis Garcia wrote:
>> "Most of the code was rewritten, which also means many possible..."
>>
>> I say: Some Kdenlive users need LTS versions instead of needing to be
>> trying latest AppImages forever.
> 
> For sure. But for that we need to reach stability. That's what we hope
> to achieve with the 18.08 release.

I'm waiting for LTS versions since Kdenlive v0.9
An LTS version of a software receives updates (during years)
independently of mainline version. This also allows to be trusted and
productive in OS distributions.
Think in M.Firefox LTS versions.


>> 4. File -> Open : Can't open folders with non-english characters in
>> their names (double-click and no effect).
> 
> I cannot reproduce. Will do more tests. You mean you have a project file
> stored in a folder with non standard characters and cannot access the
> content of the folder from the file > open dialog ? Can you copy/paste
> the name of the problematic folder in a mail?

/home/user/Vídeos

LANG=ca_ES.UTF-8
XDG_CURRENT_DESKTOP=GNOME


From jacob at nerdonthestreet.com  Sat Jul  7 07:51:33 2018
From: jacob at nerdonthestreet.com (Jacob Kauffmann)
Date: Sat, 07 Jul 2018 01:51:33 -0500
Subject: Refactoring Branch Feedback
Message-ID: <1530946293.3781811.1432800008.59204803@webmail.messagingengine.com>

Hello,

In response to the call for testing, I created a video of myself trying out the new refactoring branch. It's a bit long, but interested parties can watch it here: https://nerdonthestreet.com/episode/tech/testing-kdenlive (or at https://youtu.be/cNLjoajFUUY if you would prefer YouTube.)

I recorded on Thursday night, so it's slightly outdated, but much of it should still be relevant. My issues mainly boiled down to:

- New A/V splitting workflow: I already knew this would be a big change for me, and I understand I'll have to adapt. However, there are a number of inconsistencies and quirks which are probably making this change more annoying than it needs to be. (For example, video clips magically turning into audio clips when moved to an audio track, even though you can't put audio clips in a video track.) I saw that you've already made an update to have the default number of audio and video tracks be equal, and that's a good start, but I think more usability testing could be done in this area as a whole. Anything that can be done to make it easier to drag things around with this new system, should be done, in my opinion.

- Performance issues: I'm not sure if it has to do with the AppImage format, but I'm getting noticeably lower performance in the refactoring version compared to the current version. For reference, I've got a 6th generation Core i7 processor and a current-generation flagship GPU, so I'm hoping the performance is more like what I'm used to by the time refactoring becomes stable. I've got no data to back this up, but it seems like some of the performance issues are caused by Kdenlive working really hard to keep audio and video clips locked together while moving them around, since we're doing the whole vertically-symmetrical automatic group moving instead of static grouping like the current version.

- Minor UI quirks: again, not sure what's caused by AppImage and what's caused by Kdenlive, but some context menu items are missing (while the corresponding features are still present), the "Split Audio" context menu item shows up in a lot of places where it shouldn't (do we need that any more since it's now always going to be split?), the right-click context menu now doesn't show up until I release the mouse button, etc. I'm also not too pleased with how the timeline tracks, clips, and waveforms look a lot clunkier now. Just because it's professional-grade doesn't mean it can't look nice; on the contrary, it's beginning to look like Cinelerra or something else from the 90's.

- Bugs & crashes: the "gain" effect isn't saving my input properly, it seems to be saving 1% of the entered value (e.g. if I type in 200%, it gets set to 2%.) Custom keyboard shortcuts for effects are not working for me. I had some very unexpected behavior when layering several audio clips on top of each other; sometimes, only the topmost (or bottommost) clip would sound while playing. I also had a decent number of crashes. I see that there's a version for "AppImage - Refactoring" in the bug tracker already, so I may try and report some of those issues over there if you want users to start doing that.

Hopefully this feedback is helpful, and if anyone has tips on how to deal with the big workflow change, I'd appreciate hearing them. Thanks to everyone who's working on this, I know you're working hard on it & I hope it turns out well.

- Jacob Kauffmann

P.S. Someone else mentioned something about an LTS branch. I just wanted to mention that back when you did the port to KF5 (and some other refactoring happening at the time), I downloaded the last pre-rewrite version from git and used that for 6-8 months while the actual "stable" branch had its issues worked out. I know that's not a great thing for development because it means less feedback, but if anyone else around here is (like me) concerned about the upcoming changes, I wanted to remind people that it's an option. I prefer to stay on the current version, but with the current state of things, I might end up doing the same thing I did last time.

From jb at kdenlive.org  Sun Jul  8 16:10:39 2018
From: jb at kdenlive.org (Jean-Baptiste Mardelle)
Date: Sun, 08 Jul 2018 17:10:39 +0200
Subject: Refactoring Branch Feedback
In-Reply-To: <1530946293.3781811.1432800008.59204803@webmail.messagingengine.com>
References: <1530946293.3781811.1432800008.59204803@webmail.messagingengine.com>
Message-ID: <2710f7fa-bec6-46e6-af5a-749b677fe643@kdenlive.org>

On Saturday, July 7, 2018 8:51:33 AM CEST, Jacob Kauffmann wrote:
> Hello,
>
> In response to the call for testing, I created a video of 
> myself trying out the new refactoring branch. It's a bit long, 
> but interested parties can watch it here: 
> https://nerdonthestreet.com/episode/tech/testing-kdenlive (or at 
> https://youtu.be/cNLjoajFUUY if you would prefer YouTube.)
>

Hello Jacob!

> I recorded on Thursday night, so it's slightly outdated, but 
> much of it should still be relevant. My issues mainly boiled 
> down to:

Thanks a lot for your feedback, that is very useful for us.


> - New A/V splitting workflow: I already knew this would be a 
> big change for me, and I understand I'll have to adapt. However, 
> there are a number of inconsistencies and quirks which are 
> probably making this change more annoying than it needs to be. 
> (For example, video clips magically turning into audio clips 
> when moved to an audio track, even though you can't put audio 
> clips in a video track.) I saw that you've already made an 
> update to have the default number of audio and video tracks be 
> equal, and that's a good start, but I think more usability 
> testing could be done in this area as a whole. Anything that can 
> be done to make it easier to drag things around with this new 
> system, should be done, in my opinion.

I agree that the current state is a bit annoying compared with the previous 
workflow. We will need to discuss it and make improvments.


> - Performance issues: I'm not sure if it has to do with the 
> AppImage format, but I'm getting noticeably lower performance in 
> the refactoring version compared to the current version. For 
> reference, I've got a 6th generation Core i7 processor and a 
> current-generation flagship GPU, so I'm hoping the performance 
> is more like what I'm used to by the time refactoring becomes 
> stable. I've got no data to back this up, but it seems like some 
> of the performance issues are caused by Kdenlive working really 
> hard to keep audio and video clips locked together while moving 
> them around, since we're doing the whole vertically-symmetrical 
> automatic group moving instead of static grouping like the 
> current version.

Yes, there are several performance issues, but we probably won't solve them 
until 18.08.1

> - Minor UI quirks: again, not sure what's caused by AppImage 
> and what's caused by Kdenlive, but some context menu items are 
> missing (while the corresponding features are still present), 
> the "Split Audio" context menu item shows up in a lot of places 
> where it shouldn't (do we need that any more since it's now 
> always going to be split?), the right-click context menu now 
> doesn't show up until I release the mouse button, etc. I'm also 
> not too pleased with how the timeline tracks, clips, and 
> waveforms look a lot clunkier now. Just because it's 
> professional-grade doesn't mean it can't look nice; on the 
> contrary, it's beginning to look like Cinelerra or something 
> else from the 90's.

I fixed the context menu on click and audio split issues. I agree that UI 
could look nicer but not out top priority

> - Bugs & crashes: the "gain" effect isn't saving my input 
> properly, it seems to be saving 1% of the entered value (e.g. if 
> I type in 200%, it gets set to 2%.) Custom keyboard shortcuts 
> for effects are not working for me. I had some very unexpected 
> behavior when layering several audio clips on top of each other; 
> sometimes, only the topmost (or bottommost) clip would sound 
> while playing. I also had a decent number of crashes. I see that 
> there's a version for "AppImage - Refactoring" in the bug 
> tracker already, so I may try and report some of those issues 
> over there if you want users to start doing that.

Gain should be fixed, as well as audio mixing problems (were occuring after 
a track insertion).

> Hopefully this feedback is helpful, and if anyone has tips on 
> how to deal with the big workflow change, I'd appreciate hearing 
> them. Thanks to everyone who's working on this, I know you're 
> working hard on it & I hope it turns out well.


I will try to upload a new AppImage in the next 2 days so you can do some 
more testing.

> - Jacob Kauffmann
>
> P.S. Someone else mentioned something about an LTS branch. I 
> just wanted to mention that back when you did the port to KF5 
> (and some other refactoring happening at the time), I downloaded 
> the last pre-rewrite version from git and used that for 6-8 
> months while the actual "stable" branch had its issues worked 
> out. I know that's not a great thing for development because it 
> means less feedback, but if anyone else around here is (like me) 
> concerned about the upcoming changes, I wanted to remind people 
> that it's an option. I prefer to stay on the current version, 
> but with the current state of things, I might end up doing the 
> same thing I did last time.
>
>


From informatica at actiu.net  Sun Jul  8 17:23:51 2018
From: informatica at actiu.net (Narcis Garcia)
Date: Sun, 8 Jul 2018 18:23:51 +0200
Subject: The future is almost here
In-Reply-To: <73934900-04cb-bbf7-97e9-f5b93a025e25@kdenlive.org>
Message-ID: <21765e09-3d42-113c-63ef-c001d0edb8a0@actiu.net>

El 06/07/18 a les 16:35, Jean-Baptiste Mardelle ha escrit:
>> 1. tested a clean DVD/PAL project: Add an MP4 to project {Audio AAC,
>> video H.264, clip monitor plays perfect}. When trying to drop in
>> timeline (first track, with label "V3"), action is prevented with a
>> message "No available audio track for split operation".
>> I suppost default project timeline should have well-ordered tracks:
>> V1,V2,A1,A2 and there should be a preferences option to not use new
>> separation feature.
> 
> Done, 2 audio tracks and 2 video tracks by default now.
> Disabling the automatic separation will not be possible anymore. However
> I also find it annoying to have that issue. Maybe we can find a way to
> make it more flexible, we need to think about it. For example insert
> video only if no audio track is available, or add icons that allow to
> drag only audio part or only video part from the bin or monitor.

I think that: V1,A1 ; V2,A2 is better than: V1;V2;A1;A2

"," means smaller separation than ";"

From wpessoa at outlook.com  Sun Jul  8 23:04:20 2018
From: wpessoa at outlook.com (Willian Pessoa)
Date: Sun, 8 Jul 2018 22:04:20 +0000
Subject: [Help] Where and how to send my code contribuition?
Message-ID: <MWHPR0501MB37075FC5866FBBB466102F43B0450@MWHPR0501MB3707.namprd05.prod.outlook.com>

Hi!

I added three "safe zone" overlays to (clip)monitor. It can be seen here<https://phabricator.kde.org/T5434>.

I need some help to push these changes to main branch (rectoring timeline or master?). I already created an phabricator account. I try push my branch to remote, but I received this message: "fatal: remote error: service not enabled: /kdenlive.git".

How and where I should push my branch to pull-request and revision? Is there some manual for it?

How you can see, I am not acquainted to phabricator and KDE's code contributions process.

Thanks!
Willian Pesssoa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180708/1225cf48/attachment.html>

From french.ebook.lover at gmail.com  Sun Jul  8 23:57:17 2018
From: french.ebook.lover at gmail.com (alcinos)
Date: Mon, 9 Jul 2018 00:57:17 +0200
Subject: [Help] Where and how to send my code contribuition?
In-Reply-To: <MWHPR0501MB37075FC5866FBBB466102F43B0450@MWHPR0501MB3707.namprd05.prod.outlook.com>
References: <MWHPR0501MB37075FC5866FBBB466102F43B0450@MWHPR0501MB3707.namprd05.prod.outlook.com>
Message-ID: <CAHJBWfn+prWLi5KAcksD0fFD6kYFDuEZYws5rhRP43_AHjfAcw@mail.gmail.com>

Hi Willian,

You first need to create an account on https://identity.kde.org/.

Then, you need to log in to the phabricator: https://phabricator.kde.org/,
and submit a diff, as explained here:
https://community.kde.org/Infrastructure/Phabricator#Posting_a_Patch_using_the_website
You can add Jean-Baptiste Mardelle (mardelle) and me (alcinos) to the
reviewers.

Thanks for your contribution!

Alcinos

2018-07-09 0:04 GMT+02:00 Willian Pessoa <wpessoa at outlook.com>:

> Hi!
>
> I added three "safe zone" overlays to (clip)monitor. It can be seen here
> <https://phabricator.kde.org/T5434>.
>
> I need some help to push these changes to main branch (rectoring timeline
> or master?). I already created an phabricator account. I try push my branch
> to remote, but I received this message: "fatal: remote error: service not
> enabled: /kdenlive.git".
>
> How and where I should push my branch to pull-request and revision? Is
> there some manual for it?
>
> How you can see, I am not acquainted to phabricator and KDE's code
> contributions process.
>
> Thanks!
> Willian Pesssoa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180709/16cd2be2/attachment.html>

From snd.noise at gmail.com  Mon Jul  9 14:39:51 2018
From: snd.noise at gmail.com (farid abdelnour)
Date: Mon, 9 Jul 2018 10:39:51 -0300
Subject: Beware of FFMPEG 4 and MLT 6.8
In-Reply-To: <CAAHf8rfyYUM8KNF3H7jFN3BcZ2oh3NhSTJj-Xvaa6wEixsvhUg@mail.gmail.com>
References: <CAHMxv36nX2kaxQgkaLdm4TtHoiK69QbnBRBGhC6PCAyBwom-Fw@mail.gmail.com>
 <CAAHf8rfyYUM8KNF3H7jFN3BcZ2oh3NhSTJj-Xvaa6wEixsvhUg@mail.gmail.com>
Message-ID: <CAHMxv37nNUGZp=j6vPM7S9EZKuSxwRUk+CHXOnhOMhG8k2-FpQ@mail.gmail.com>

6.10 will be the requirement for the refactored version.

2018-07-04 18:58 GMT-03:00 Javier Agustìn Fernàndez Arroyo <elhoir at gmail.com
>:

> hello,
>
> I guess ffmpeg 4.0.1 doesnt work too, but...
> What about new MLT 6.10 ?
>
> On Wed, May 16, 2018 at 4:18 PM, farid abdelnour <snd.noise at gmail.com>
> wrote:
>
>> Do not use FFMPEG 4 and MLT 6.8 since they break Kdenlive's
>> functionalities.
>>
>> I have already reported this to Archlinux packagers. If your distribution
>> has those versions please inform us or report it to them.
>>
>> Thanks
>>
>> --
>> 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/20180709/128cdfae/attachment.html>

From camille.moulin at free.fr  Wed Jul 11 19:31:30 2018
From: camille.moulin at free.fr (Camille)
Date: Wed, 11 Jul 2018 20:31:30 +0200
Subject: Tests & CI
Message-ID: <6b2384a4-a44d-61fa-ee1c-7b7124cfc156@free.fr>

Hi all,

As discussed during the Paris sprint and more recently in a Kdenlive 
café with Nicolas, I'd like to help setting up a relevant CI for Kdenlive.

There is already a general KDE CI that builds  the code for various 
platforms [1], but I have yet to understand how it works, mostly from an 
organizational point of view. Nicolas mentioned that the main point of 
Contact is Ben Cooksley, but  I have not contacted him yet. One thing to 
be noted, is that this CI could be already useful, for instance, as it 
shows that  requiring MLT 6.10 broke the build. [2]

In parallel, I have set up an experimental CI on Gitlab.com, because it 
seemed to me that it could have a few  advantages, especially in terms  
of flexibility.

What I have done so far is just to mirror the code and write a simple 
.gitlab-ci.yml file on the refactoring_timeline branch: it builds the 
code, runs cppcheck  in the "build" stage then runs "build/runTests 
-platform offscreen" in the test stage.

The results of cppcheck are available in the artifacts of the build 
stage [3] and the result of runTests are in the logs of the test stage 
[4]. Please note that the test stage fails not because of the results of 
the tests, but because runTests segfaults (purposely, if I recall 
correctly). One detail : it should be easy  to get email notifications 
on the results (I get them as owner of the repo, but  I guess anyone 
could subscribe).

So, in short term, I see two (non exclusive) possible actions :

- Contact  KDE infrastructure team to have an instance that suits you ; 
that means : the OS of your choice, the right branch to be tested 
(refactoring_timeline I guess ) and automatically running runTests

- Clean/adapt the .gitlab-ci.yml file, add it to the code repo and 
automatically mirror the repo on an official kdenlive acccount on a 
gitlab instance (it doesn't have to be gitlab.com).

What do you think about it?

Cheers,

Camille


[1] https://build.kde.org/job/Applications%20kdenlive%20kf5-qt5%20SUSEQt5.9/

[2] 
https://build.kde.org/job/Applications%20kdenlive%20kf5-qt5%20SUSEQt5.9/34/

[3] 
https://gitlab.com/camillem/kdenlive-mirror/-/jobs/81024447/artifacts/download

[4] https://gitlab.com/camillem/kdenlive-mirror/-/jobs/81024448



From aacid at kde.org  Wed Jul 11 22:50:46 2018
From: aacid at kde.org (Albert Astals Cid)
Date: Wed, 11 Jul 2018 23:50:46 +0200
Subject: Tests & CI
In-Reply-To: <6b2384a4-a44d-61fa-ee1c-7b7124cfc156@free.fr>
References: <6b2384a4-a44d-61fa-ee1c-7b7124cfc156@free.fr>
Message-ID: <11260571.KoiOtQAdd0@xps>

El dimecres, 11 de juliol de 2018, a les 20:31:30 CEST, Camille va escriure:
> Hi all,
> 
> As discussed during the Paris sprint and more recently in a Kdenlive
> café with Nicolas, I'd like to help setting up a relevant CI for Kdenlive.
> 
> There is already a general KDE CI that builds  the code for various
> platforms [1], but I have yet to understand how it works, mostly from an
> organizational point of view. Nicolas mentioned that the main point of
> Contact is Ben Cooksley, but  I have not contacted him yet. One thing to
> be noted, is that this CI could be already useful, for instance, as it
> shows that  requiring MLT 6.10 broke the build. [2]
> 
> In parallel, I have set up an experimental CI on Gitlab.com, because it
> seemed to me that it could have a few  advantages, especially in terms 
> of flexibility.
> 
> What I have done so far is just to mirror the code and write a simple
> .gitlab-ci.yml file on the refactoring_timeline branch: it builds the
> code, runs cppcheck  in the "build" stage then runs "build/runTests
> -platform offscreen" in the test stage.
> 
> The results of cppcheck are available in the artifacts of the build
> stage [3] and the result of runTests are in the logs of the test stage
> [4]. Please note that the test stage fails not because of the results of
> the tests, but because runTests segfaults (purposely, if I recall
> correctly). One detail : it should be easy  to get email notifications
> on the results (I get them as owner of the repo, but  I guess anyone
> could subscribe).
> 
> So, in short term, I see two (non exclusive) possible actions :
> 
> - Contact  KDE infrastructure team to have an instance that suits you ;
> that means : the OS of your choice, the right branch to be tested
> (refactoring_timeline I guess ) and automatically running runTests
> 
> - Clean/adapt the .gitlab-ci.yml file, add it to the code repo and
> automatically mirror the repo on an official kdenlive acccount on a
> gitlab instance (it doesn't have to be gitlab.com).
> 
> What do you think about it?

Please try to work with the upstream CI, I personally think it's not a great 
idea to have two CI, since it means duplicating the efforts.

Best Regards,
  Albert

> 
> Cheers,
> 
> Camille
> 
> 
> [1] https://build.kde.org/job/Applications%20kdenlive%20kf5-qt5%20SUSEQt5.9/
> 
> [2]
> https://build.kde.org/job/Applications%20kdenlive%20kf5-qt5%20SUSEQt5.9/34/
> 
> [3]
> https://gitlab.com/camillem/kdenlive-mirror/-/jobs/81024447/artifacts/downlo
> ad
> 
> [4] https://gitlab.com/camillem/kdenlive-mirror/-/jobs/81024448





From dj_kaza at hotmail.com  Thu Jul 12 16:29:01 2018
From: dj_kaza at hotmail.com (Dale Powell)
Date: Thu, 12 Jul 2018 15:29:01 +0000
Subject: KDenLive free(): invalid pointer error at startup
Message-ID: <AM0PR10MB2004112956C2378C5760A9668F590@AM0PR10MB2004.EURPRD10.PROD.OUTLOOK.COM>

Hello all.

I reported almost a week ago that KDenLive has stopped working on my Ubuntu Studio 18.04 laptop on the forums to an astounding silence. This is a rather serious issue meaning the program can not even be started!! Can somebody please assist me on getting this fixed before I just give up with this software entirely despite it seeming to be the best video editor on Linux?

https://forum.kde.org/viewtopic.php?f=265&t=153147
KDenLive wont start - free(): invalid pointer &bull; KDE Community Forums <https://forum.kde.org/viewtopic.php?f=265&t=153147>
using ubuntu this was working fine a few weeks ago last time i booted was only to check and try and help another member on the ubuntu forums and it
forum.kde.org



Regards Dale.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180712/5a1bfe36/attachment.html>

From snd.noise at gmail.com  Thu Jul 12 16:48:34 2018
From: snd.noise at gmail.com (farid abdelnour)
Date: Thu, 12 Jul 2018 12:48:34 -0300
Subject: KDenLive free(): invalid pointer error at startup
In-Reply-To: <AM0PR10MB2004112956C2378C5760A9668F590@AM0PR10MB2004.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB2004112956C2378C5760A9668F590@AM0PR10MB2004.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <CAHMxv36XMfxUVWo-gqzhAFrRQzBFd9VwB1BmJHtBPx1J81LTRg@mail.gmail.com>

Hi Dale

2018-07-12 12:29 GMT-03:00 Dale Powell <dj_kaza at hotmail.com>:

> Hello all.
>
> I reported almost a week ago that KDenLive has stopped working on my
> Ubuntu Studio 18.04 laptop on the forums to an astounding silence. This is
> a rather serious issue meaning the program can not even be started!! Can
> somebody please assist me on getting this fixed before I just give up with
> this software entirely despite it seeming to be the best video editor on
> Linux?
>


Sorry for the delay, currently all our efforts are on the refactoring
branch. You must state the version of Kdenlive and MLT so we can try to
debug better. A wild guess though, I'd say you are using a PPA or a version
from the repos, eitherway those are rather obsolete AFAIK. Have you tried
using the AppImage and see if that works? You can get it from here:
https://kdenlive.org/en/download/

Cheers


>
> https://forum.kde.org/viewtopic.php?f=265&t=153147
> KDenLive wont start - free(): invalid pointer &bull; KDE Community Forums
> <https://forum.kde.org/viewtopic.php?f=265&t=153147>
> using ubuntu this was working fine a few weeks ago last time i booted was
> only to check and try and help another member on the ubuntu forums and it
> forum.kde.org
>
>
> Regards Dale.
>



-- 
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/20180712/fc8d4e61/attachment.html>

From dj_kaza at hotmail.com  Thu Jul 12 17:04:00 2018
From: dj_kaza at hotmail.com (Dale Powell)
Date: Thu, 12 Jul 2018 16:04:00 +0000
Subject: KDenLive free(): invalid pointer error at startup
In-Reply-To: <CAHMxv36XMfxUVWo-gqzhAFrRQzBFd9VwB1BmJHtBPx1J81LTRg@mail.gmail.com>
References: <AM0PR10MB2004112956C2378C5760A9668F590@AM0PR10MB2004.EURPRD10.PROD.OUTLOOK.COM>,
 <CAHMxv36XMfxUVWo-gqzhAFrRQzBFd9VwB1BmJHtBPx1J81LTRg@mail.gmail.com>
Message-ID: <AM0PR10MB2004EDE9AAB51885B08E78988F590@AM0PR10MB2004.EURPRD10.PROD.OUTLOOK.COM>

Farid.

Thanks for the speedy response here.

Yes the appImage works, I actually found and tried that a just a few minutes after posting. Still this is no reason why the versions on both your ppa and Canonical's ones should have stopped working in the last few weeks!

The linked thread goes through all the steps I have tried, I didn't feel it needed repeating here... But I didn't mention versions.

Canonical: 4:17.12.3-0ubuntu1
PPA: 4:18.04.1+git201805021218~ubuntu18.04.1

I guess for now I'll just have to remember to open it via the appImage and manually check if newer versions are out.....

Dale.

________________________________
From: kdenlive <kdenlive-bounces at kde.org> on behalf of farid abdelnour <snd.noise at gmail.com>
Sent: 12 July 2018 15:48
To: kdenlive at kde.org
Subject: Re: KDenLive free(): invalid pointer error at startup

Hi Dale

2018-07-12 12:29 GMT-03:00 Dale Powell <dj_kaza at hotmail.com<mailto:dj_kaza at hotmail.com>>:
Hello all.

I reported almost a week ago that KDenLive has stopped working on my Ubuntu Studio 18.04 laptop on the forums to an astounding silence. This is a rather serious issue meaning the program can not even be started!! Can somebody please assist me on getting this fixed before I just give up with this software entirely despite it seeming to be the best video editor on Linux?


Sorry for the delay, currently all our efforts are on the refactoring branch. You must state the version of Kdenlive and MLT so we can try to debug better. A wild guess though, I'd say you are using a PPA or a version from the repos, eitherway those are rather obsolete AFAIK. Have you tried using the AppImage and see if that works? You can get it from here: https://kdenlive.org/en/download/

Cheers


https://forum.kde.org/viewtopic.php?f=265&t=153147
KDenLive wont start - free(): invalid pointer &bull; KDE Community Forums <https://forum.kde.org/viewtopic.php?f=265&t=153147>
using ubuntu this was working fine a few weeks ago last time i booted was only to check and try and help another member on the ubuntu forums and it
forum.kde.org<http://forum.kde.org>



Regards Dale.



--
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/20180712/a41d141b/attachment-0001.html>

From jb at kdenlive.org  Thu Jul 12 17:29:21 2018
From: jb at kdenlive.org (jb at kdenlive.org)
Date: Thu, 12 Jul 2018 18:29:21 +0200
Subject: Tests & CI
In-Reply-To: <6b2384a4-a44d-61fa-ee1c-7b7124cfc156@free.fr>
References: <6b2384a4-a44d-61fa-ee1c-7b7124cfc156@free.fr>
Message-ID: <7A48A839-FBF7-49AC-AC8B-7230D2AC6060@kdenlive.org>

On July 11, 2018 8:31:30 PM GMT+02:00, Camille <camille.moulin at free.fr> wrote:
>Hi all,
>
>As discussed during the Paris sprint and more recently in a Kdenlive 
>café with Nicolas, I'd like to help setting up a relevant CI for
>Kdenlive.

Hello Camille,

Thanks for following on this topic! That's something we always wanted but never had time to take care of.

>There is already a general KDE CI that builds  the code for various 
>platforms [1], but I have yet to understand how it works, mostly from
>an 
>organizational point of view. Nicolas mentioned that the main point of 
>Contact is Ben Cooksley, but  I have not contacted him yet. One thing
>to 
>be noted, is that this CI could be already useful, for instance, as it 
>shows that  requiring MLT 6.10 broke the build. [2]

The best way to contact the KDE sysadmins is to open a phabricator request for the sysadmins.

https://phabricator.kde.org/maniphest/task/edit/form/2/


>In parallel, I have set up an experimental CI on Gitlab.com, because it
>
>seemed to me that it could have a few  advantages, especially in terms 
>
>of flexibility.
>
>What I have done so far is just to mirror the code and write a simple 
>.gitlab-ci.yml file on the refactoring_timeline branch: it builds the 
>code, runs cppcheck  in the "build" stage then runs "build/runTests 
>-platform offscreen" in the test stage.
>
>The results of cppcheck are available in the artifacts of the build 
>stage [3] and the result of runTests are in the logs of the test stage 
>[4]. Please note that the test stage fails not because of the results
>of 
>the tests, but because runTests segfaults (purposely, if I recall 
>correctly). One detail : it should be easy  to get email notifications 
>on the results (I get them as owner of the repo, but  I guess anyone 
>could subscribe).
>
>So, in short term, I see two (non exclusive) possible actions :
>
>- Contact  KDE infrastructure team to have an instance that suits you ;
>
>that means : the OS of your choice, the right branch to be tested 
>(refactoring_timeline I guess ) and automatically running runTests
>
>- Clean/adapt the .gitlab-ci.yml file, add it to the code repo and 
>automatically mirror the repo on an official kdenlive acccount on a 
>gitlab instance (it doesn't have to be gitlab.com).
>
>What do you think about it?

If you have some time, as Albert mentionned it would be great to contact the kde sysadmins to check if we can have something equivalent whithout too much hassle.

Let us know,
Thanks
Jean-Baptiste



>Cheers,
>
>Camille
>
>
>[1]
>https://build.kde.org/job/Applications%20kdenlive%20kf5-qt5%20SUSEQt5.9/
>
>[2] 
>https://build.kde.org/job/Applications%20kdenlive%20kf5-qt5%20SUSEQt5.9/34/
>
>[3] 
>https://gitlab.com/camillem/kdenlive-mirror/-/jobs/81024447/artifacts/download
>
>[4] https://gitlab.com/camillem/kdenlive-mirror/-/jobs/81024448

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180712/82f0fe1f/attachment.html>

From johnar1 at protonmail.com  Mon Jul 16 06:51:34 2018
From: johnar1 at protonmail.com (johnar1)
Date: Mon, 16 Jul 2018 01:51:34 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
Message-ID: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>

System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
I have successfully compiled mlt and ffmpeg with nvenc support using the official nvenc headers stripped from the Nvidia SDK.
Rendering the first minute of the 1080p Sintel version, with 4 threads specified and my nvenc profile, finishes in 10 seconds.
Sintel can be downloaded here: [https://durian.blender.org/download/](https://durian.blender.org/download/[/url)
Nvenc Profile: (compatible with recent mlt versions who are nvenc enabled by deafult)
f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k

Now here is the problem that I do not understand:
Using the latest version of kdenlive from the kdenlive-master ppa combined with the newly compiled versions of ffmpeg and mlt works perfectly, but only under very specific circumstances.

I have only been able to get rendering with nvenc to work properly when I use and open this specific kdenlive [b]save file[/b] which I made of the first minute of the Sintel short film with the Appimage Version of Kdenlive. After launching the ppa/installed version of kdenlive and opening this save file, rendering with nvenc works flawlessly.

If I simply start a new project, adding the whole Sintel short film to the project bin, cutting the first minute and render it, nvenc simply does not work and the render time is tripled, despite having changed nothing else, including the nvenc render profile.

If I create a save file of the first minute of Sintel with the installed version and open it on the Appimage version, nvenc does not work again.

Conclusion: There must be something in this save file, maybe a parameter, additonal settings or any type of code not present in the default kdenlive project profiles, which enables NVENC.

I would greatly appreciate it if we could find out the source of this problem together.

Kdenlive Appimage Save File with which NVENC works:
https://pastebin.com/rzjR57DJ

PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
https://pastebin.com/3uQ8sP0C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180716/a5b2bcb9/attachment.html>

From eugen.mohr at gmx.net  Mon Jul 16 14:48:21 2018
From: eugen.mohr at gmx.net (Eugen Mohr)
Date: Mon, 16 Jul 2018 15:48:21 +0200
Subject: Aw: Incredible Render Performance In Kdenlive With NVENC - But 1
 Big Problem
In-Reply-To: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
Message-ID: <trinity-35eef544-cd49-4417-8d2e-7035ae3c462f-1531748901619@3c-app-gmx-bs74>

An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180716/ed8c434a/attachment.html>

From jb at kdenlive.org  Mon Jul 16 18:06:34 2018
From: jb at kdenlive.org (jb at kdenlive.org)
Date: Mon, 16 Jul 2018 19:06:34 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <trinity-35eef544-cd49-4417-8d2e-7035ae3c462f-1531748901619@3c-app-gmx-bs74>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <trinity-35eef544-cd49-4417-8d2e-7035ae3c462f-1531748901619@3c-app-gmx-bs74>
Message-ID: <82686459-7E32-409E-A5AE-0F87CE6B6AC0@kdenlive.org>



On July 16, 2018 3:48:21 PM GMT+02:00, Eugen Mohr <eugen.mohr at gmx.net> wrote:
>On a first look:
>
>File which runs:
>
>MLT version 6.7.0
>
>frame_rate_den="1"
>
>60 fps
>
>name="length">53282
>
> 
>
>file which doesn't run:
>
>MLT version 6.10.0 → version of the Kdenlive refactoring
>
>frame_rate_den="1001"
>
>29.97 fps
>
>name="length">00:14:48;00
>
> 
>
>check this parameters with other files
>

Thanks for this feedback. This could be very interesting and definitely deserves some investigation.

As Eugen stated, the main difference seems to be in the project profile. The first 'working' project uses a 60fps profile, while the broken one uses a 29.97 fps profile. And your source video (sintel) is a 24fps video. These parameters might affect nvenc. 

I would recommand testing directly with Mlt in a terminal:

melt -profile atsc_1080p_60 sintel.mp4 out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2

This should render the first minute with a 60fps profile

Then:

melt -profile atsc_1080p_2997 sintel.mp4 out=1800 -consumer avformat:result-2997.mp4 f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2

This should render the first minute at 29.97 fps.

(Just adjust the path to the sintel.mp4 original video in my command lines).

What are the render times? Keep in mind that rendering at 60fps means you render twice as many frames compared to 29.97fps...

Some comparison between nvenc and the normal h264 encoder would be nice. Also interesting to see if the time gain is still there when you add effects, for example add:

-attach sepia
Just before the '-consumer' paramt to add a sepia effect to the clip

Best regards
Jean-Baptiste


>
>Gesendet: Montag, 16. Juli 2018 um 07:51 Uhr
>Von: johnar1 <johnar1 at protonmail.com>
>An: "kdenlive at kde.org" <kdenlive at kde.org>
>Betreff: Incredible Render Performance In Kdenlive With NVENC - But 1
>Big Problem
>
> 
>
> 
>
>System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>
>I have successfully compiled mlt and ffmpeg with nvenc support using
>the official nvenc headers stripped from the Nvidia SDK.
>
>Rendering the first minute of the 1080p Sintel version, with 4 threads
>specified and my nvenc profile, finishes in 10 seconds.
>
>Sintel can be downloaded here: https://durian.blender.org/download/
>
>Nvenc Profile: (compatible with recent mlt versions who are nvenc
>enabled by deafult)
>
>f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2
>ab=384k
>
> 
>
> 
>
>Now here is the problem that I do not understand:
>
>Using the latest version of kdenlive from the kdenlive-master ppa
>combined with the newly compiled versions of ffmpeg and mlt works
>perfectly, but only under very specific circumstances.
>
> 
>
>I have only been able to get rendering with nvenc to work properly when
>I use and open this specific kdenlive [b]save file[/b] which I made of
>the first minute of the Sintel short film with the Appimage Version of
>Kdenlive. After launching the ppa/installed version of kdenlive and
>opening this save file, rendering with nvenc works flawlessly.
>
> 
>
>If I simply start a new project, adding the whole Sintel short film to
>the project bin, cutting the first minute and render it, nvenc simply
>does not work and the render time is tripled, despite having changed
>nothing else, including the nvenc render profile.
>
> 
>
>If I create a save file of the first minute of Sintel with the
>installed version and open it on the Appimage version, nvenc does not
>work again.
>
> 
>
>Conclusion: There must be something in this save file, maybe a
>parameter, additonal settings or any type of code not present in the
>default kdenlive project profiles, which enables NVENC.
>
> 
>
>I would greatly appreciate it if we could find out the source of this
>problem together.
>
> 
>
>Kdenlive Appimage Save File with which NVENC works:
>
>https://pastebin.com/rzjR57DJ
>
> 
>
>PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
>
>https://pastebin.com/3uQ8sP0C
>
> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From eugen.mohr at gmx.net  Sun Jul 22 18:46:10 2018
From: eugen.mohr at gmx.net (Eugen Mohr)
Date: Sun, 22 Jul 2018 19:46:10 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <L5vd1Ru8t_U14MQPnbewIdIDfxGKhspPtrUF5ngJtkaj39TyZhY4bm6CVsAHdrZqofrLkIF54Rde-tNikpMmqg4Ym2azxnjzkI798P2RSRw=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <trinity-35eef544-cd49-4417-8d2e-7035ae3c462f-1531748901619@3c-app-gmx-bs74>
 <L5vd1Ru8t_U14MQPnbewIdIDfxGKhspPtrUF5ngJtkaj39TyZhY4bm6CVsAHdrZqofrLkIF54Rde-tNikpMmqg4Ym2azxnjzkI798P2RSRw=@protonmail.com>
Message-ID: <3e373d63-bd5a-d202-5259-68550abb5c04@gmx.net>

You render it with MLT 11.0. Kdenlive refactoring runs MLT 10.0. Try 
with the actual AppImage 18.08.Beta 18.


Am 22.07.2018 um 16:15 schrieb johnar1:
> Ok, I think I have isolated the problem now.
>
> I just compiled kdenlive from the latest git, everything works and I 
> get the following warning before launching it. (Screenshot attached)
>
> The following codecs are missing: libx265, nvenc_h264, h264_nvenc
>
> The Appimage version does not state this warning as it probably 
> already comes with the necessary stuff.
>
> So the final question is, how do I get these codecs?
> The only thing you can manually install that is related to nvenc, are 
> the headers themselves, which I already have installed.
>
> Any ideas?
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 16, 2018 2:48 PM, Eugen Mohr <eugen.mohr at gmx.net> wrote:
>
>> On a first look:
>>
>> File which runs:
>>
>> MLT version 6.7.0
>>
>> frame_rate_den="1"
>>
>> 60 fps
>>
>> name="length">53282
>>
>>
>> file which doesn't run:
>>
>> MLT version 6.10.0 → version of the Kdenlive refactoring
>>
>> frame_rate_den="1001"
>>
>> 29.97 fps
>>
>> name="length">00:14:48;00
>>
>>
>> check this parameters with other files
>>
>>
>>
>> *Gesendet:* Montag, 16. Juli 2018 um 07:51 Uhr
>> *Von:* johnar1 <johnar1 at protonmail.com>
>> *An:* "kdenlive at kde.org" <kdenlive at kde.org>
>> *Betreff:* Incredible Render Performance In Kdenlive With NVENC - But 
>> 1 Big Problem
>>
>>
>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>> I have successfully compiled mlt and ffmpeg with nvenc support using 
>> the official nvenc headers stripped from the Nvidia SDK.
>> Rendering the first minute of the 1080p Sintel version, with 4 
>> threads specified and my nvenc profile, finishes in 10 seconds.
>> Sintel can be downloaded here: https://durian.blender.org/download/ 
>> <https://durian.blender.org/download/[/url>
>> Nvenc Profile: (compatible with recent mlt versions who are nvenc 
>> enabled by deafult)
>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
>>
>>
>> Now here is the problem that I do not understand:
>> Using the latest version of kdenlive from the kdenlive-master ppa 
>> combined with the newly compiled versions of ffmpeg and mlt works 
>> perfectly, but only under very specific circumstances.
>>
>> I have only been able to get rendering with nvenc to work properly 
>> when I use and open this specific kdenlive [b]save file[/b] which I 
>> made of the first minute of the Sintel short film with the Appimage 
>> Version of Kdenlive. After launching the ppa/installed version of 
>> kdenlive and opening this save file, rendering with nvenc works 
>> flawlessly.
>>
>> If I simply start a new project, adding the whole Sintel short film 
>> to the project bin, cutting the first minute and render it, nvenc 
>> simply does not work and the render time is tripled, despite having 
>> changed nothing else, including the nvenc render profile.
>>
>> If I create a save file of the first minute of Sintel with the 
>> installed version and open it on the Appimage version, nvenc does not 
>> work again.
>>
>> Conclusion: There must be something in this save file, maybe a 
>> parameter, additonal settings or any type of code not present in the 
>> default kdenlive project profiles, which enables NVENC.
>>
>> I would greatly appreciate it if we could find out the source of this 
>> problem together.
>>
>> Kdenlive Appimage Save File with which NVENC works:
>> https://pastebin.com/rzjR57DJ
>>
>> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
>> https://pastebin.com/3uQ8sP0C
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180722/c67f108d/attachment-0001.html>

From juku.trump at gmail.com  Sun Jul 22 23:21:08 2018
From: juku.trump at gmail.com (Juku Trump)
Date: Mon, 23 Jul 2018 01:21:08 +0300
Subject: Contributing to Kdenlive
Message-ID: <CAHzaz1+hx=PmJXM-2jA5w3sqbQSs3xpjwGgfsujXnWC9AQ+-wg@mail.gmail.com>

Hi,

My name is Juku. I am a film hobbyist and I have been using Kdenlive for
about 8 years. As I'm also a developer, I thought I would try my hand on
contributing to Kdenlive.

I have mostly been a web developer so far, so I do not have much experience
with C++ (except for some tutorials) and I have never done any Qt
development.

I viewed the "Junior Jobs" section in Kdenlive Development Information page
and tried to fix #384511 for start ("New project window does not fit to
laptop screen (1366x768)"). Thanks to a hint by Christoph Feck in the
comments below that bug, I got it fixed and submitted the patch (D14281
<https://phabricator.kde.org/D14281>) for review.

Currently I'm having some trouble with the automated tests. Should they
succeed in their current state or are there some known problems with them?

It would be helpful if someone would suggest some other tasks which I could
start with.

Thanks,
Juku
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180723/c8d03f14/attachment.html>

From eugen.mohr at gmx.net  Mon Jul 23 20:39:58 2018
From: eugen.mohr at gmx.net (Eugen Mohr)
Date: Mon, 23 Jul 2018 21:39:58 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <nJaNMnbPuNMX2q4QhM4xyHs31Jd-6GNEP0O9hPjpFKAhDIsIjroWam-iymqzycTv8k2kj0x7pQtAsFaJ5MC1qlscQmbV2nGfqSFkpdrFQqk=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <trinity-35eef544-cd49-4417-8d2e-7035ae3c462f-1531748901619@3c-app-gmx-bs74>
 <L5vd1Ru8t_U14MQPnbewIdIDfxGKhspPtrUF5ngJtkaj39TyZhY4bm6CVsAHdrZqofrLkIF54Rde-tNikpMmqg4Ym2azxnjzkI798P2RSRw=@protonmail.com>
 <3e373d63-bd5a-d202-5259-68550abb5c04@gmx.net>
 <nJaNMnbPuNMX2q4QhM4xyHs31Jd-6GNEP0O9hPjpFKAhDIsIjroWam-iymqzycTv8k2kj0x7pQtAsFaJ5MC1qlscQmbV2nGfqSFkpdrFQqk=@protonmail.com>
Message-ID: <51a0cb2e-ba59-7274-a94b-0c7e8c72858f@gmx.net>


Am 23.07.2018 um 19:35 schrieb johnar1:
> Thanks again, for your efforts! (Ich vermute, dass du ebenfalls 
> Deutscher bist, also nochmal danke haha.)
> *I have 100% and with absolute certainty figured out what the actual 
> problem is.*
>
> I have compiled melt from the latest git available here: 
> https://github.com/mltframework/mlt/releases/tag/v6.10.0
> I just ./configure and make && make install
> I then use this melt executable by selecting it in the kdenlive 
> environment tab.
>
> Here is the kicker:
>
> When I use ./configure --enable-gpl --enable-gpl3  to compile melt---> 
> NVENC does not --->CPU utilization 100% on 1 core, 20% - 30% on the 
> rest, GPU utilization= 4%
>
> When  I use ./configure without these two flags ---> NVENC works --> 
> CPU utilization = 100% on all cores /GPU utilization = 90%
>
>
> Here is kicker number 2:
>
> I originally thought this was a problem with NVENC, but that is not true.
>
> When compiling with --enable-gpl and --enable-gpl3, Kdenlive 
> subsequently only uses 1 single CPU core for rendering. (Despite 
> having 4 threads selected in the render dialog, kdenlive environment 
> and even in the generated render script)
>
> *That *is why NVENC *appears* to not work, because the CPU is not 
> being used properly, hence it cannot feed the GPU enough frames. There 
> is some GPU utilization
>
> Now I have read that enabling the license also enables a bunch of qt 
> modules, and qt obviously heavily pertains to concurrent CPU scheduling.
>
> You'd think that the problem could be solved by simply not using 
> --enable-gpl and --enable-gpl3, but unfortunately that excludes the 
> libmltqt.so module, which I need for title clips in kdenlive.
>
>
> So basically, without gpl I get crazy render speeds and almost 100% 
> GPU/CPU utilization, but not title clips.
> And with gpl only 1 single CPU core is being used for rendering, no 
> matter how many times I specify 4 threads, but title clips work.
> *_
> _*
> *_We are sooooo close to solving this omg!_**_
> _*
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 22, 2018 6:46 PM, Eugen Mohr <eugen.mohr at gmx.net> wrote:
>
>>
>>
>> You render it with MLT 11.0. Kdenlive refactoring runs MLT 10.0. Try 
>> with the actual AppImage 18.08.Beta 18.
>>
>>
>>
>> Am 22.07.2018 um 16:15 schrieb johnar1:
>>> Ok, I think I have isolated the problem now.
>>>
>>> I just compiled kdenlive from the latest git, everything works and I 
>>> get the following warning before launching it. (Screenshot attached)
>>>
>>> The following codecs are missing: libx265, nvenc_h264, h264_nvenc
>>>
>>> The Appimage version does not state this warning as it probably 
>>> already comes with the necessary stuff.
>>>
>>> So the final question is, how do I get these codecs?
>>> The only thing you can manually install that is related to nvenc, 
>>> are the headers themselves, which I already have installed.
>>>
>>> Any ideas?
>>>
>>>
>>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On July 16, 2018 2:48 PM, Eugen Mohr <eugen.mohr at gmx.net> wrote:
>>>
>>>> On a first look:
>>>>
>>>> File which runs:
>>>>
>>>> MLT version 6.7.0
>>>>
>>>> frame_rate_den="1"
>>>>
>>>> 60 fps
>>>>
>>>> name="length">53282
>>>>
>>>>
>>>> file which doesn't run:
>>>>
>>>> MLT version 6.10.0 → version of the Kdenlive refactoring
>>>>
>>>> frame_rate_den="1001"
>>>>
>>>> 29.97 fps
>>>>
>>>> name="length">00:14:48;00
>>>>
>>>>
>>>> check this parameters with other files
>>>>
>>>>
>>>>
>>>> *Gesendet:* Montag, 16. Juli 2018 um 07:51 Uhr
>>>> *Von:* johnar1 <johnar1 at protonmail.com>
>>>> *An:* "kdenlive at kde.org" <kdenlive at kde.org>
>>>> *Betreff:* Incredible Render Performance In Kdenlive With NVENC - 
>>>> But 1 Big Problem
>>>>
>>>>
>>>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>>>> I have successfully compiled mlt and ffmpeg with nvenc support 
>>>> using the official nvenc headers stripped from the Nvidia SDK.
>>>> Rendering the first minute of the 1080p Sintel version, with 4 
>>>> threads specified and my nvenc profile, finishes in 10 seconds.
>>>> Sintel can be downloaded here: https://durian.blender.org/download/ 
>>>> <https://durian.blender.org/download/[/url>
>>>> Nvenc Profile: (compatible with recent mlt versions who are nvenc 
>>>> enabled by deafult)
>>>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 
>>>> ab=384k
>>>>
>>>>
>>>> Now here is the problem that I do not understand:
>>>> Using the latest version of kdenlive from the kdenlive-master ppa 
>>>> combined with the newly compiled versions of ffmpeg and mlt works 
>>>> perfectly, but only under very specific circumstances.
>>>>
>>>> I have only been able to get rendering with nvenc to work properly 
>>>> when I use and open this specific kdenlive [b]save file[/b] which I 
>>>> made of the first minute of the Sintel short film with the Appimage 
>>>> Version of Kdenlive. After launching the ppa/installed version of 
>>>> kdenlive and opening this save file, rendering with nvenc works 
>>>> flawlessly.
>>>>
>>>> If I simply start a new project, adding the whole Sintel short film 
>>>> to the project bin, cutting the first minute and render it, nvenc 
>>>> simply does not work and the render time is tripled, despite having 
>>>> changed nothing else, including the nvenc render profile.
>>>>
>>>> If I create a save file of the first minute of Sintel with the 
>>>> installed version and open it on the Appimage version, nvenc does 
>>>> not work again.
>>>>
>>>> Conclusion: There must be something in this save file, maybe a 
>>>> parameter, additonal settings or any type of code not present in 
>>>> the default kdenlive project profiles, which enables NVENC.
>>>>
>>>> I would greatly appreciate it if we could find out the source of 
>>>> this problem together.
>>>>
>>>> Kdenlive Appimage Save File with which NVENC works:
>>>> https://pastebin.com/rzjR57DJ
>>>>
>>>> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
>>>> https://pastebin.com/3uQ8sP0C
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180723/2e9254e9/attachment.html>

From j at ganomi.com  Tue Jul 24 14:55:54 2018
From: j at ganomi.com (Jiri Kanicky)
Date: Tue, 24 Jul 2018 23:55:54 +1000
Subject: AppImage-18.08-beta 18 - issue with fonts in Effects window.
Message-ID: <e4e25cf3-2680-5b80-cf68-c4bddf9938c6@ganomi.com>

Hi,

Just would like to report issue with fonts in Effects window. Please see 
screenshot.



Debian Sid
Running HighDPI (1.4) in KDE.

Thanks,
Jiri

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180724/3a443ed5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hfeomghcbbfnhhnl.png
Type: image/png
Size: 66171 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180724/3a443ed5/attachment-0001.png>

From johnar1 at protonmail.com  Tue Jul 24 22:26:01 2018
From: johnar1 at protonmail.com (johnar1)
Date: Tue, 24 Jul 2018 17:26:01 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
Message-ID: <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>

Hey guys, I have some more info.

Hey Eugen, I have some more info.

For this test I used mlt 6.11, successfully compiled by Dan Dennedy's build-melt.sh

The test file that I am using is the 1080p version of Sintel.
https://durian.blender.org/download/

CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04

In order to check melt and isolate the problem I simply rendered the first minute of the Sintel short film with the following command:
(This is not the /bin/melt, but the script which launches it with the correct libs)

/home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc preset=slow
[CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization (NVENC): 80%] [Render Time: 20s]

It obviously works perfectly.

Now when I select this melt in the kdenlive environment, and also ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt folder, yields the following results when rendering the first minute of Sintel.
[CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization (NVENC): 8%] [Render Time: 2m54s]
Something in kdenlive breaks parallel processing, only allowing 1 single core to be fully utilized.
And I have tested every single version of kdenlive available on this earth.
Every app image, including the refractoring version and every single ppa version, including stable, dev and master.

Also generating and launching the render script from the terminal yields the same result.

RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
MELT="/home/frank/melt/20180724/melt"

SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
TARGET_0="file:///home/frank/Documents/untitled.mkv"
PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
$RENDERER $PARAMETERS_0

I have also tested different kdenlive_render executables/libs with the same result.

I should note, that using the kdenlive_multirender script in conjunction with the generated render script by kdenlive, while specifying 4 threads, the CPU uses 2 cores at 100%.
https://github.com/unfa/kdenlive-multirender

Now as I have described before, when I compile melt without enabling gpl, the 1 minute of Sintel renders perfectly again, with full utilization on both the CPU and GPU, but from within Kdenlive this time.

I conclude that this problem is somehow caused by Kdenlive and related to qt, but I do not possess the knowhow to further analyze it.

With the latest 18.08 Beta18 and the most recent QT version, 2 cores instead of 1 are now being utilized at 100% with the NVENC profile and 100% on all 4 cores using the MP4 h264 profile.

So this is 100% a QT issue with NVENC, but I need further insight from a professionals like yourselves.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 16, 2018 7:51 AM, johnar1 <johnar1 at protonmail.com> wrote:

> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
> I have successfully compiled mlt and ffmpeg with nvenc support using the official nvenc headers stripped from the Nvidia SDK.
> Rendering the first minute of the 1080p Sintel version, with 4 threads specified and my nvenc profile, finishes in 10 seconds.
> Sintel can be downloaded here: [https://durian.blender.org/download/](https://durian.blender.org/download/[/url)
> Nvenc Profile: (compatible with recent mlt versions who are nvenc enabled by deafult)
> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
>
> Now here is the problem that I do not understand:
> Using the latest version of kdenlive from the kdenlive-master ppa combined with the newly compiled versions of ffmpeg and mlt works perfectly, but only under very specific circumstances.
>
> I have only been able to get rendering with nvenc to work properly when I use and open this specific kdenlive [b]save file[/b] which I made of the first minute of the Sintel short film with the Appimage Version of Kdenlive. After launching the ppa/installed version of kdenlive and opening this save file, rendering with nvenc works flawlessly.
>
> If I simply start a new project, adding the whole Sintel short film to the project bin, cutting the first minute and render it, nvenc simply does not work and the render time is tripled, despite having changed nothing else, including the nvenc render profile.
>
> If I create a save file of the first minute of Sintel with the installed version and open it on the Appimage version, nvenc does not work again.
>
> Conclusion: There must be something in this save file, maybe a parameter, additonal settings or any type of code not present in the default kdenlive project profiles, which enables NVENC.
>
> I would greatly appreciate it if we could find out the source of this problem together.
>
> Kdenlive Appimage Save File with which NVENC works:
> https://pastebin.com/rzjR57DJ
>
> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
> https://pastebin.com/3uQ8sP0C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180724/37dda124/attachment.html>

From vpinon at kde.org  Wed Jul 25 01:23:12 2018
From: vpinon at kde.org (Vincent Pinon)
Date: Wed, 25 Jul 2018 02:23:12 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
Message-ID: <5784499.zTCVWVEayy@pad>

Hello,

I don't know how precisely you do the job in kdenlive
(you could share the .kdenlive, the .sh.mlt, a screenshot),

one thing I suspect is the track composition (automatic transparency):
if you keep the default high quality choice,
kdenlive adds "composite & transform" transitions that are based on Qt.
So without gpl / qt module, MLT skips these transitions.

Could you run your test switching to "no transparency"?
(toolbar just above timeline)

Thanks for you enthusiastic investigations :)

Vincent

Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :

Hey guys, I have some more info.



Hey Eugen, I have some more info.

For this test I used mlt 6.11, successfully compiled by Dan Dennedy's build-melt.sh

The test file that I am using is the 1080p version of Sintel.

https://durian.blender.org/download/

CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04

In order to check melt and isolate the problem I simply rendered the first minute of the Sintel short film with the following command:

(This is not the /bin/melt, but the script which launches it with the correct libs)



/home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc preset=slow

[CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization (NVENC): 80%] [Render Time: 20s]



It obviously works perfectly.



Now when I select this melt in the kdenlive environment, and also ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt folder, yields the following results when rendering the first minute of Sintel.

[CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization (NVENC): 8%] [Render Time: 2m54s]

Something in kdenlive breaks parallel processing, only allowing 1 single core to be fully utilized.

And I have tested every single version of kdenlive available on this earth.

Every app image, including the refractoring version and every single ppa version, including stable, dev and master.



Also generating and launching the render script from the terminal yields the same result.

RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
MELT="/home/frank/melt/20180724/melt"

SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
TARGET_0="file:///home/frank/Documents/untitled.mkv"
PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
$RENDERER $PARAMETERS_0


I have also tested different kdenlive_render executables/libs with the same result.

I should note, that using the kdenlive_multirender script in conjunction with the generated render script by kdenlive, while specifying 4 threads, the CPU uses 2 cores at 100%.

https://github.com/unfa/kdenlive-multirender



Now as I have described before, when I compile melt without enabling gpl, the 1 minute of Sintel renders perfectly again, with full utilization on both the CPU and GPU, but from within Kdenlive this time.

I conclude that this problem is somehow caused by Kdenlive and related to qt, but I do not possess the knowhow to further analyze it.

With the latest 18.08 Beta18 and the most recent QT version, 2 cores instead of 1 are now being utilized at 100% with the NVENC profile and 100% on all 4 cores using the MP4 h264 profile.

So this is 100% a QT issue with NVENC, but I need further insight from a professionals like yourselves.





Sent with ProtonMail Secure Email.



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On July 16, 2018 7:51 AM, johnar1 <johnar1 at protonmail.com> wrote:







System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16

I have successfully compiled mlt and ffmpeg with nvenc support using the official nvenc headers stripped from the Nvidia SDK.

Rendering the first minute of the 1080p Sintel version, with 4 threads specified and my nvenc profile, finishes in 10 seconds.

Sintel can be downloaded here: https://durian.blender.org/download/

Nvenc Profile: (compatible with recent mlt versions who are nvenc enabled by deafult)

f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k





Now here is the problem that I do not understand:

Using the latest version of kdenlive from the kdenlive-master ppa combined with the newly compiled versions of ffmpeg and mlt works perfectly, but only under very specific circumstances.



I have only been able to get rendering with nvenc to work properly when I use and open this specific kdenlive [b]save file[/b] which I made of the first minute of the Sintel short film with the Appimage Version of Kdenlive. After launching the ppa/installed version of kdenlive and opening this save file, rendering with nvenc works flawlessly.



If I simply start a new project, adding the whole Sintel short film to the project bin, cutting the first minute and render it, nvenc simply does not work and the render time is tripled, despite having changed nothing else, including the nvenc render profile.



If I create a save file of the first minute of Sintel with the installed version and open it on the Appimage version, nvenc does not work again.



Conclusion: There must be something in this save file, maybe a parameter, additonal settings or any type of code not present in the default kdenlive project profiles, which enables NVENC.



I would greatly appreciate it if we could find out the source of this problem together.



Kdenlive Appimage Save File with which NVENC works:

https://pastebin.com/rzjR57DJ



PPA/Installed Version of Kdenlive created Save File which breaks NVENC:

https://pastebin.com/3uQ8sP0C







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180725/19ac718b/attachment-0001.html>

From johnar1 at protonmail.com  Wed Jul 25 20:38:31 2018
From: johnar1 at protonmail.com (johnar1)
Date: Wed, 25 Jul 2018 15:38:31 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <5784499.zTCVWVEayy@pad>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
Message-ID: <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>

Dear Mr. Vincent Pinon,

if that is in fact your real name, my first born son shall henceforth be known as Vincent.

Your suggestion was spot on and according to my tests so far I believe it works.

Here are my findings:

Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC enabled,  Kdenlive 18.04 AppImage

.)Track Composition - "None"
[CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%] [Render Time: 15s]
I noticed however, that transitions such as for example Slide or Composite are rendered improperly, with certain interference patterns.

After consulting the documentation, I realized that this should be fixed by disabling any surrounding empty tracks, but so far I have not been able to achieve that.

.)Track Composition - "Preview"
[CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%] [Render Time: 20s]

I conclude that the best of both worlds comes into play with this option enabled.
Both the GPU and CPU are almost fully utilized, while it appears that transitions are rendered correctly.

I will do more thorough testing and read any documentation available, as I absolutely want to understand what exactly these options do.

I think it's a bit counterintutive to have "High Quality" enabled by default, which so heavily impacts performance, while in my opinion not making enough of an effort to alert the user to the extreme effects it may have on render times.

I literally spent 72 hours straight, compiling every single version of melt and kdenlive, documenting and testing every possible compilation parameter variation, performance reviews with every available version of Ubuntu, corresponding kernels and nvidia drivers, and every remotely related kdenlive option or workarounds.

This has  definitely shortened my life span by about 3 - 4 years.

I would like to extend my gratitude to you, good sir.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 25, 2018 2:23 AM, Vincent Pinon <vpinon at kde.org> wrote:

> Hello,
>
> I don't know how precisely you do the job in kdenlive
>
> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>
> one thing I suspect is the track composition (automatic transparency):
>
> if you keep the default high quality choice,
>
> kdenlive adds "composite & transform" transitions that are based on Qt.
>
> So without gpl / qt module, MLT skips these transitions.
>
> Could you run your test switching to "no transparency"?
>
> (toolbar just above timeline)
>
> Thanks for you enthusiastic investigations :)
>
> Vincent
>
> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
>
> Hey guys, I have some more info.
>
> Hey Eugen, I have some more info.
>
> For this test I used mlt 6.11, successfully compiled by Dan Dennedy's build-melt.sh
>
> The test file that I am using is the 1080p version of Sintel.
>
> https://durian.blender.org/download/
>
> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04
>
> In order to check melt and isolate the problem I simply rendered the first minute of the Sintel short film with the following command:
>
> (This is not the /bin/melt, but the script which launches it with the correct libs)
>
> /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc preset=slow
>
> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization (NVENC): 80%] [Render Time: 20s]
>
> It obviously works perfectly.
>
> Now when I select this melt in the kdenlive environment, and also ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt folder, yields the following results when rendering the first minute of Sintel.
>
> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization (NVENC): 8%] [Render Time: 2m54s]
>
> Something in kdenlive breaks parallel processing, only allowing 1 single core to be fully utilized.
>
> And I have tested every single version of kdenlive available on this earth.
>
> Every app image, including the refractoring version and every single ppa version, including stable, dev and master.
>
> Also generating and launching the render script from the terminal yields the same result.
>
> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>
> MELT="/home/frank/melt/20180724/melt"
>
> SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
>
> TARGET_0="file:///home/frank/Documents/untitled.mkv"
>
> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
>
> $RENDERER $PARAMETERS_0
>
> I have also tested different kdenlive_render executables/libs with the same result.
>
> I should note, that using the kdenlive_multirender script in conjunction with the generated render script by kdenlive, while specifying 4 threads, the CPU uses 2 cores at 100%.
>
> https://github.com/unfa/kdenlive-multirender
>
> Now as I have described before, when I compile melt without enabling gpl, the 1 minute of Sintel renders perfectly again, with full utilization on both the CPU and GPU, but from within Kdenlive this time.
>
> I conclude that this problem is somehow caused by Kdenlive and related to qt, but I do not possess the knowhow to further analyze it.
>
> With the latest 18.08 Beta18 and the most recent QT version, 2 cores instead of 1 are now being utilized at 100% with the NVENC profile and 100% on all 4 cores using the MP4 h264 profile.
>
> So this is 100% a QT issue with NVENC, but I need further insight from a professionals like yourselves.
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On July 16, 2018 7:51 AM, johnar1 <johnar1 at protonmail.com> wrote:
>
> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>
> I have successfully compiled mlt and ffmpeg with nvenc support using the official nvenc headers stripped from the Nvidia SDK.
>
> Rendering the first minute of the 1080p Sintel version, with 4 threads specified and my nvenc profile, finishes in 10 seconds.
>
> Sintel can be downloaded here: [https://durian.blender.org/download/](https://durian.blender.org/download/[/url)
>
> Nvenc Profile: (compatible with recent mlt versions who are nvenc enabled by deafult)
>
> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
>
> Now here is the problem that I do not understand:
>
> Using the latest version of kdenlive from the kdenlive-master ppa combined with the newly compiled versions of ffmpeg and mlt works perfectly, but only under very specific circumstances.
>
> I have only been able to get rendering with nvenc to work properly when I use and open this specific kdenlive [b]save file[/b] which I made of the first minute of the Sintel short film with the Appimage Version of Kdenlive. After launching the ppa/installed version of kdenlive and opening this save file, rendering with nvenc works flawlessly.
>
> If I simply start a new project, adding the whole Sintel short film to the project bin, cutting the first minute and render it, nvenc simply does not work and the render time is tripled, despite having changed nothing else, including the nvenc render profile.
>
> If I create a save file of the first minute of Sintel with the installed version and open it on the Appimage version, nvenc does not work again.
>
> Conclusion: There must be something in this save file, maybe a parameter, additonal settings or any type of code not present in the default kdenlive project profiles, which enables NVENC.
>
> I would greatly appreciate it if we could find out the source of this problem together.
>
> Kdenlive Appimage Save File with which NVENC works:
>
> https://pastebin.com/rzjR57DJ
>
> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
>
> https://pastebin.com/3uQ8sP0C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180725/d3d8eabf/attachment-0001.html>

From jb at kdenlive.org  Thu Jul 26 08:20:04 2018
From: jb at kdenlive.org (Jean-Baptiste Mardelle)
Date: Thu, 26 Jul 2018 09:20:04 +0200
Subject: Contributing to Kdenlive
In-Reply-To: <CAHzaz1+hx=PmJXM-2jA5w3sqbQSs3xpjwGgfsujXnWC9AQ+-wg@mail.gmail.com>
References: <CAHzaz1+hx=PmJXM-2jA5w3sqbQSs3xpjwGgfsujXnWC9AQ+-wg@mail.gmail.com>
Message-ID: <2d303fc3-cf32-edf6-f5b3-1d98b79915e3@kdenlive.org>


On 23.07.2018 00:21, Juku Trump wrote:
> Hi,
>

Hello Juku!

Thanks a lot for your contribution and sorry for my late reply. Your 
help is very welcome. I have now merged your contribution. Regarding the 
tests, they need some work and currently don't all pass and crash. We 
need to work on that.

Regarding other tasks, we really need to make a list of UI improvements 
that could be done without too much knowledge of the whole code. I will 
try to spend some time on it tomorrow, help is welcome. But basically, 
if there is any UI related thing that you want to improve, feel free to 
ask and we can guide you if needed.

Best regards,

Jean-Baptiste

> My name is Juku. I am a film hobbyist and I have been using Kdenlive 
> for about 8 years. As I'm also a developer, I thought I would try my 
> hand on contributing to Kdenlive.
>
> I have mostly been a web developer so far, so I do not have much 
> experience with C++ (except for some tutorials) and I have never done 
> any Qt development.
>
> I viewed the "Junior Jobs" section in Kdenlive Development Information 
> page and tried to fix #384511 for start ("New project window does not 
> fit to laptop screen (1366x768)"). Thanks to a hint by Christoph Feck 
> in the comments below that bug, I got it fixed and submitted the patch 
> (D14281 <https://phabricator.kde.org/D14281>) for review.
>
> Currently I'm having some trouble with the automated tests. Should 
> they succeed in their current state or are there some known problems 
> with them?
>
> It would be helpful if someone would suggest some other tasks which I 
> could start with.
>
> Thanks,
> Juku

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180726/6061a750/attachment.html>

From jb at kdenlive.org  Thu Jul 26 08:30:43 2018
From: jb at kdenlive.org (Jean-Baptiste Mardelle)
Date: Thu, 26 Jul 2018 09:30:43 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
 <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
Message-ID: <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>


On 25.07.2018 21:38, johnar1 wrote:
> Dear Mr. Vincent Pinon,
>
> if that is in fact your real name, my first born son shall henceforth 
> be known as Vincent.
>
> Your suggestion was spot on and according to my tests so far I believe 
> it works.
>
> Here are my findings:
>
> Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC 
> enabled,  Kdenlive 18.04 AppImage

Hello Johnar,

I am myself trying to setup a working nvenc environment and hope to make 
some more tests.
>
> .)Track Composition - "None"
> [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%] 
> [Render Time: 15s]
> I noticed however, that transitions such as for example Slide or 
> Composite are rendered improperly, with certain interference patterns.
>
> After consulting the documentation, I realized that this should be 
> fixed by disabling any surrounding empty tracks, but so far I have not 
> been able to achieve that.
>
> .)Track Composition - "Preview"
> [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%] 
> [Render Time: 20s]
>
> I conclude that the best of both worlds comes into play with this 
> option enabled.
> Both the GPU and CPU are almost fully utilized, while it appears that 
> transitions are rendered correctly.
>
So if I understand correctly, rendering the same project with Track 
compositing set to "High Quality" has a major impact and you get this 
result:
[CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization 
(NVENC): 8%] [Render Time: 2m54s]

This seems strange to me since Kdenlive's "high quality" track 
compositing uses the qtblend transition that should automatically be 
bypassed when there is no transparency in the video. If you can confirm 
that and that this simple change in track compositing has such an impact 
this definitely has to be checked... Also, Dan recently fixed many of 
the "affine" transition issue, so it should give results similar to the 
"qtblend" transition but may be faster..

Thanks for all your investigations, I hope to come back with more infos 
once I successfully achieve my setup.

Best regards
Jean-Baptiste


> I will do more thorough testing and read any documentation available, 
> as I absolutely want to understand what exactly these options do.
>
> I think it's a bit counterintutive to have "High Quality" enabled by 
> default, which so heavily impacts performance, while in my opinion not 
> making enough of an effort to alert the user to the extreme effects it 
> may have on render times.
>
> I literally spent 72 hours straight, compiling every single version of 
> melt and kdenlive, documenting and testing every possible compilation 
> parameter variation, performance reviews with every available version 
> of Ubuntu, corresponding kernels and nvidia drivers, and every 
> remotely related kdenlive option or workarounds.
>
> This has  definitely shortened my life span by about 3 - 4 years.
>
> I would like to extend my gratitude to you, good sir.
>
>
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 25, 2018 2:23 AM, Vincent Pinon <vpinon at kde.org> wrote:
>
>> Hello,
>>
>> I don't know how precisely you do the job in kdenlive
>>
>> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>>
>> one thing I suspect is the track composition (automatic transparency):
>>
>> if you keep the default high quality choice,
>>
>> kdenlive adds "composite & transform" transitions that are based on Qt.
>>
>> So without gpl / qt module, MLT skips these transitions.
>>
>> Could you run your test switching to "no transparency"?
>>
>> (toolbar just above timeline)
>>
>> Thanks for you enthusiastic investigations :)
>>
>> Vincent
>>
>> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
>>
>> Hey guys, I have some more info.
>>
>> Hey Eugen, I have some more info.
>>
>> For this test I used mlt 6.11, successfully compiled by Dan Dennedy's 
>> build-melt.sh
>>
>> The test file that I am using is the 1080p version of Sintel.
>>
>> _https://durian.blender.org/download/_
>>
>> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 
>> 18.04
>>
>> In order to check melt and isolate the problem I simply rendered the 
>> first minute of the Sintel short film with the following command:
>>
>> (This is not the /bin/melt, but the script which launches it with the 
>> correct libs)
>>
>> /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv 
>> out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc 
>> preset=slow
>>
>> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization 
>> (NVENC): 80%] [Render Time: 20s]
>>
>> It obviously works perfectly.
>>
>> Now when I select this melt in the kdenlive environment, and also 
>> ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt folder, 
>> yields the following results when rendering the first minute of Sintel.
>>
>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization 
>> (NVENC): 8%] [Render Time: 2m54s]
>>
>> Something in kdenlive breaks parallel processing, only allowing 1 
>> single core to be fully utilized.
>>
>> And I have tested every single version of kdenlive available on this 
>> earth.
>>
>> Every app image, including the refractoring version and every single 
>> ppa version, including stable, dev and master.
>>
>> Also generating and launching the render script from the terminal 
>> yields the same result.
>>
>> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>> MELT="/home/frank/melt/20180724/melt"
>> SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
>> TARGET_0="file:///home/frank/Documents/untitled.mkv"
>> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat - 
>> $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
>> $RENDERER $PARAMETERS_0
>>
>> I have also tested different kdenlive_render executables/libs with 
>> the same result.
>>
>> I should note, that using the kdenlive_multirender script in 
>> conjunction with the generated render script by kdenlive, while 
>> specifying 4 threads, the CPU uses 2 cores at 100%.
>>
>> _https://github.com/unfa/kdenlive-multirender_
>>
>> Now as I have described before, when I compile melt without enabling 
>> gpl, the 1 minute of Sintel renders perfectly again, with full 
>> utilization on both the CPU and GPU, but from within Kdenlive this time.
>>
>> I conclude that this problem is somehow caused by Kdenlive and 
>> related to qt, but I do not possess the knowhow to further analyze it.
>>
>> With the latest 18.08 Beta18 and the most recent QT version, 2 cores 
>> instead of 1 are now being utilized at 100% with the NVENC profile 
>> and 100% on all 4 cores using the MP4 h264 profile.
>>
>> So this is 100% a QT issue with NVENC, but I need further insight 
>> from a professionals like yourselves.
>>
>> Sent with _ProtonMail_ <https://protonmail.com> Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>
>> On July 16, 2018 7:51 AM, johnar1 <johnar1 at protonmail.com> wrote:
>>
>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>>
>> I have successfully compiled mlt and ffmpeg with nvenc support using 
>> the official nvenc headers stripped from the Nvidia SDK.
>>
>> Rendering the first minute of the 1080p Sintel version, with 4 
>> threads specified and my nvenc profile, finishes in 10 seconds.
>>
>> Sintel can be downloaded here: _https://durian.blender.org/download/_ 
>> <https://durian.blender.org/download/[/url>
>>
>> Nvenc Profile: (compatible with recent mlt versions who are nvenc 
>> enabled by deafult)
>>
>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
>>
>> Now here is the problem that I do not understand:
>>
>> Using the latest version of kdenlive from the kdenlive-master ppa 
>> combined with the newly compiled versions of ffmpeg and mlt works 
>> perfectly, but only under very specific circumstances.
>>
>> I have only been able to get rendering with nvenc to work properly 
>> when I use and open this specific kdenlive [b]save file[/b] which I 
>> made of the first minute of the Sintel short film with the Appimage 
>> Version of Kdenlive. After launching the ppa/installed version of 
>> kdenlive and opening this save file, rendering with nvenc works 
>> flawlessly.
>>
>> If I simply start a new project, adding the whole Sintel short film 
>> to the project bin, cutting the first minute and render it, nvenc 
>> simply does not work and the render time is tripled, despite having 
>> changed nothing else, including the nvenc render profile.
>>
>> If I create a save file of the first minute of Sintel with the 
>> installed version and open it on the Appimage version, nvenc does not 
>> work again.
>>
>> Conclusion: There must be something in this save file, maybe a 
>> parameter, additonal settings or any type of code not present in the 
>> default kdenlive project profiles, which enables NVENC.
>>
>> I would greatly appreciate it if we could find out the source of this 
>> problem together.
>>
>> Kdenlive Appimage Save File with which NVENC works:
>>
>> _https://pastebin.com/rzjR57DJ_
>>
>> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
>>
>> _https://pastebin.com/3uQ8sP0C_
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180726/122d773c/attachment-0001.html>

From johnar1 at protonmail.com  Thu Jul 26 09:02:58 2018
From: johnar1 at protonmail.com (johnar1)
Date: Thu, 26 Jul 2018 04:02:58 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
 <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
 <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>
Message-ID: <kh1MyUwt3vqLZKClvzue_xwmmPaM_GQ7SMLBrVUI9FOwVMXimxL9iHTNpfcqofsd0GoMG6bggcImQLfkhn41EI7TGUtUq5rPUzC7vKJvXS8=@protonmail.com>

Hello Jean,

yes that is correct, switching from High Quality compositing had a major impact on performance and I am not sure why.

I can help you out getting NVENC to work.
What platform are you on?

There are a couple things to be mindful of.

.)After installing the graphics driver you need to genereate an xorg.conf
.)Install the NVENC Headers from here: https://github.com/lutris/ffmpeg-nvenc/issues/22
.)Use the correct NVENC parameter in your render profile, as the current one has been deprecated.
Here's my profile:
f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60 preset= slow g=120 bf=2

.)You need to compile ffmpeg and mlt with the following flags:
./configure --enable-nvenc --enable-cuvid --enable-nonfree

Or if you don't want to compile yourself you can simply use the melt binary + libs from the most recent Shotcut build.
https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2

Instructions here:
https://www.youtube.com/watch?v=X14GvmBpq08&t=314s

This will get NVENC working 100%.
When you're done, you need to track the GPU utilization in the driver and make sure it is working. How many frames your GPU can push depends on the power of your CPU. I use the kdenlive_multirender  script to ensure 100% utilization on all cores and subsequently higher GPU utilization.
https://github.com/unfa/kdenlive-multirender

Let's keep in touch!

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle <jb at kdenlive.org> wrote:

> On 25.07.2018 21:38, johnar1 wrote:
>
>> Dear Mr. Vincent Pinon,
>>
>> if that is in fact your real name, my first born son shall henceforth be known as Vincent.
>>
>> Your suggestion was spot on and according to my tests so far I believe it works.
>>
>> Here are my findings:
>>
>> Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC enabled,  Kdenlive 18.04 AppImage
>
> Hello Johnar,
>
> I am myself trying to setup a working nvenc environment and hope to make some more tests.
>
>> .)Track Composition - "None"
>> [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%] [Render Time: 15s]
>> I noticed however, that transitions such as for example Slide or Composite are rendered improperly, with certain interference patterns.
>>
>> After consulting the documentation, I realized that this should be fixed by disabling any surrounding empty tracks, but so far I have not been able to achieve that.
>>
>> .)Track Composition - "Preview"
>> [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%] [Render Time: 20s]
>>
>> I conclude that the best of both worlds comes into play with this option enabled.
>> Both the GPU and CPU are almost fully utilized, while it appears that transitions are rendered correctly.
>
> So if I understand correctly, rendering the same project with Track compositing set to "High Quality" has a major impact and you get this result:
> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization (NVENC): 8%] [Render Time: 2m54s]
>
> This seems strange to me since Kdenlive's "high quality" track compositing uses the qtblend transition that should automatically be bypassed when there is no transparency in the video. If you can confirm that and that this simple change in track compositing has such an impact this definitely has to be checked... Also, Dan recently fixed many of the "affine" transition issue, so it should give results similar to the "qtblend" transition but may be faster..
>
> Thanks for all your investigations, I hope to come back with more infos once I successfully achieve my setup.
>
> Best regards
> Jean-Baptiste
>
>> I will do more thorough testing and read any documentation available, as I absolutely want to understand what exactly these options do.
>>
>> I think it's a bit counterintutive to have "High Quality" enabled by default, which so heavily impacts performance, while in my opinion not making enough of an effort to alert the user to the extreme effects it may have on render times.
>>
>> I literally spent 72 hours straight, compiling every single version of melt and kdenlive, documenting and testing every possible compilation parameter variation, performance reviews with every available version of Ubuntu, corresponding kernels and nvidia drivers, and every remotely related kdenlive option or workarounds.
>>
>> This has  definitely shortened my life span by about 3 - 4 years.
>>
>> I would like to extend my gratitude to you, good sir.
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On July 25, 2018 2:23 AM, Vincent Pinon [<vpinon at kde.org>](mailto:vpinon at kde.org) wrote:
>>
>>> Hello,
>>>
>>> I don't know how precisely you do the job in kdenlive
>>>
>>> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>>>
>>> one thing I suspect is the track composition (automatic transparency):
>>>
>>> if you keep the default high quality choice,
>>>
>>> kdenlive adds "composite & transform" transitions that are based on Qt.
>>>
>>> So without gpl / qt module, MLT skips these transitions.
>>>
>>> Could you run your test switching to "no transparency"?
>>>
>>> (toolbar just above timeline)
>>>
>>> Thanks for you enthusiastic investigations :)
>>>
>>> Vincent
>>>
>>> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
>>>
>>> Hey guys, I have some more info.
>>>
>>> Hey Eugen, I have some more info.
>>>
>>> For this test I used mlt 6.11, successfully compiled by Dan Dennedy's build-melt.sh
>>>
>>> The test file that I am using is the 1080p version of Sintel.
>>>
>>> https://durian.blender.org/download/
>>>
>>> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04
>>>
>>> In order to check melt and isolate the problem I simply rendered the first minute of the Sintel short film with the following command:
>>>
>>> (This is not the /bin/melt, but the script which launches it with the correct libs)
>>>
>>> /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc preset=slow
>>>
>>> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization (NVENC): 80%] [Render Time: 20s]
>>>
>>> It obviously works perfectly.
>>>
>>> Now when I select this melt in the kdenlive environment, and also ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt folder, yields the following results when rendering the first minute of Sintel.
>>>
>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization (NVENC): 8%] [Render Time: 2m54s]
>>>
>>> Something in kdenlive breaks parallel processing, only allowing 1 single core to be fully utilized.
>>>
>>> And I have tested every single version of kdenlive available on this earth.
>>>
>>> Every app image, including the refractoring version and every single ppa version, including stable, dev and master.
>>>
>>> Also generating and launching the render script from the terminal yields the same result.
>>>
>>> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>>>
>>> MELT="/home/frank/melt/20180724/melt"
>>>
>>> SOURCE_0=
>>> "file:///home/frank/Documents/scripts/script001.sh.mlt"
>>>
>>> TARGET_0=
>>> "file:///home/frank/Documents/untitled.mkv"
>>>
>>> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
>>>
>>> $RENDERER $PARAMETERS_0
>>>
>>> I have also tested different kdenlive_render executables/libs with the same result.
>>>
>>> I should note, that using the kdenlive_multirender script in conjunction with the generated render script by kdenlive, while specifying 4 threads, the CPU uses 2 cores at 100%.
>>>
>>> https://github.com/unfa/kdenlive-multirender
>>>
>>> Now as I have described before, when I compile melt without enabling gpl, the 1 minute of Sintel renders perfectly again, with full utilization on both the CPU and GPU, but from within Kdenlive this time.
>>>
>>> I conclude that this problem is somehow caused by Kdenlive and related to qt, but I do not possess the knowhow to further analyze it.
>>>
>>> With the latest 18.08 Beta18 and the most recent QT version, 2 cores instead of 1 are now being utilized at 100% with the NVENC profile and 100% on all 4 cores using the MP4 h264 profile.
>>>
>>> So this is 100% a QT issue with NVENC, but I need further insight from a professionals like yourselves.
>>>
>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>
>>> On July 16, 2018 7:51 AM, johnar1 [<johnar1 at protonmail.com>](mailto:johnar1 at protonmail.com) wrote:
>>>
>>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>>>
>>> I have successfully compiled mlt and ffmpeg with nvenc support using the official nvenc headers stripped from the Nvidia SDK.
>>>
>>> Rendering the first minute of the 1080p Sintel version, with 4 threads specified and my nvenc profile, finishes in 10 seconds.
>>>
>>> Sintel can be downloaded here: [https://durian.blender.org/download/](https://durian.blender.org/download/[/url)
>>>
>>> Nvenc Profile: (compatible with recent mlt versions who are nvenc enabled by deafult)
>>>
>>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
>>>
>>> Now here is the problem that I do not understand:
>>>
>>> Using the latest version of kdenlive from the kdenlive-master ppa combined with the newly compiled versions of ffmpeg and mlt works perfectly, but only under very specific circumstances.
>>>
>>> I have only been able to get rendering with nvenc to work properly when I use and open this specific kdenlive [b]save file[/b] which I made of the first minute of the Sintel short film with the Appimage Version of Kdenlive. After launching the ppa/installed version of kdenlive and opening this save file, rendering with nvenc works flawlessly.
>>>
>>> If I simply start a new project, adding the whole Sintel short film to the project bin, cutting the first minute and render it, nvenc simply does not work and the render time is tripled, despite having changed nothing else, including the nvenc render profile.
>>>
>>> If I create a save file of the first minute of Sintel with the installed version and open it on the Appimage version, nvenc does not work again.
>>>
>>> Conclusion: There must be something in this save file, maybe a parameter, additonal settings or any type of code not present in the default kdenlive project profiles, which enables NVENC.
>>>
>>> I would greatly appreciate it if we could find out the source of this problem together.
>>>
>>> Kdenlive Appimage Save File with which NVENC works:
>>>
>>> https://pastebin.com/rzjR57DJ
>>>
>>> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
>>>
>>> https://pastebin.com/3uQ8sP0C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180726/f889e158/attachment-0001.html>

From jb at kdenlive.org  Thu Jul 26 09:47:26 2018
From: jb at kdenlive.org (jb)
Date: Thu, 26 Jul 2018 10:47:26 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <kh1MyUwt3vqLZKClvzue_xwmmPaM_GQ7SMLBrVUI9FOwVMXimxL9iHTNpfcqofsd0GoMG6bggcImQLfkhn41EI7TGUtUq5rPUzC7vKJvXS8=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
 <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
 <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>
 <kh1MyUwt3vqLZKClvzue_xwmmPaM_GQ7SMLBrVUI9FOwVMXimxL9iHTNpfcqofsd0GoMG6bggcImQLfkhn41EI7TGUtUq5rPUzC7vKJvXS8=@protonmail.com>
Message-ID: <0e9086e8-1a5a-7c1c-e917-7885d298e398@kdenlive.org>

Le 26.07.18 à 10:02, johnar1 a écrit :
> Hello Jean,
>
> yes that is correct, switching from High Quality compositing had a 
> major impact on performance and I am not sure why.
>
> I can help you out getting NVENC to work.
> What platform are you on?
>
Thanks. My main issue is the NVidia driver, since I currently use an 
Ubuntu 16.04 based distro, and FFmpeg complains about my NVIDIA driver 
version < 390. I will upgrade my distro and give some feedback tomorrow.

After that I guess a page on setting up nvenc would be nice on our wiki:
https://community.kde.org/Kdenlive/Development/KF5

Regards
Jean-Baptiste
> There are a couple things to be mindful of.
>
> .)After installing the graphics driver you need to genereate an xorg.conf
> .)Install the NVENC Headers from here: 
> https://github.com/lutris/ffmpeg-nvenc/issues/22
> .)Use the correct NVENC parameter in your render profile, as the 
> current one has been deprecated.
> Here's my profile:
> f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60 preset= 
> slow g=120 bf=2
>
> .)You need to compile ffmpeg and mlt with the following flags:
> ./configure --enable-nvenc --enable-cuvid --enable-nonfree
>
> Or if you don't want to compile yourself you can simply use the melt 
> binary + libs from the most recent Shotcut build.
> https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
>
> Instructions here:
> https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
>
> This will get NVENC working 100%.
> When you're done, you need to track the GPU utilization in the driver 
> and make sure it is working. How many frames your GPU can push depends 
> on the power of your CPU. I use the kdenlive_multirender  script to 
> ensure 100% utilization on all cores and subsequently higher GPU 
> utilization.
> https://github.com/unfa/kdenlive-multirender
>
> Let's keep in touch!
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle <jb at kdenlive.org> wrote:
>
>>
>> On 25.07.2018 21:38, johnar1 wrote:
>>> Dear Mr. Vincent Pinon,
>>>
>>> if that is in fact your real name, my first born son shall 
>>> henceforth be known as Vincent.
>>>
>>> Your suggestion was spot on and according to my tests so far I 
>>> believe it works.
>>>
>>> Here are my findings:
>>>
>>> Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC 
>>> enabled,  Kdenlive 18.04 AppImage
>>
>> Hello Johnar,
>>
>> I am myself trying to setup a working nvenc environment and hope to 
>> make some more tests.
>>
>>>
>>> .)Track Composition - "None"
>>> [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%] 
>>> [Render Time: 15s]
>>> I noticed however, that transitions such as for example Slide or 
>>> Composite are rendered improperly, with certain interference patterns.
>>>
>>> After consulting the documentation, I realized that this should be 
>>> fixed by disabling any surrounding empty tracks, but so far I have 
>>> not been able to achieve that.
>>>
>>> .)Track Composition - "Preview"
>>> [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%] 
>>> [Render Time: 20s]
>>>
>>> I conclude that the best of both worlds comes into play with this 
>>> option enabled.
>>> Both the GPU and CPU are almost fully utilized, while it appears 
>>> that transitions are rendered correctly.
>>>
>> So if I understand correctly, rendering the same project with Track 
>> compositing set to "High Quality" has a major impact and you get this 
>> result:
>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization 
>> (NVENC): 8%] [Render Time: 2m54s]
>>
>> This seems strange to me since Kdenlive's "high quality" track 
>> compositing uses the qtblend transition that should automatically be 
>> bypassed when there is no transparency in the video. If you can 
>> confirm that and that this simple change in track compositing has 
>> such an impact this definitely has to be checked... Also, Dan 
>> recently fixed many of the "affine" transition issue, so it should 
>> give results similar to the "qtblend" transition but may be faster..
>>
>> Thanks for all your investigations, I hope to come back with more 
>> infos once I successfully achieve my setup.
>>
>> Best regards
>> Jean-Baptiste
>>
>>
>>
>>> I will do more thorough testing and read any documentation 
>>> available, as I absolutely want to understand what exactly these 
>>> options do.
>>>
>>> I think it's a bit counterintutive to have "High Quality" enabled by 
>>> default, which so heavily impacts performance, while in my opinion 
>>> not making enough of an effort to alert the user to the extreme 
>>> effects it may have on render times.
>>>
>>> I literally spent 72 hours straight, compiling every single version 
>>> of melt and kdenlive, documenting and testing every possible 
>>> compilation parameter variation, performance reviews with every 
>>> available version of Ubuntu, corresponding kernels and nvidia 
>>> drivers, and every remotely related kdenlive option or workarounds.
>>>
>>> This has  definitely shortened my life span by about 3 - 4 years.
>>>
>>> I would like to extend my gratitude to you, good sir.
>>>
>>>
>>>
>>>
>>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On July 25, 2018 2:23 AM, Vincent Pinon <vpinon at kde.org> wrote:
>>>
>>>> Hello,
>>>>
>>>> I don't know how precisely you do the job in kdenlive
>>>>
>>>> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>>>>
>>>> one thing I suspect is the track composition (automatic transparency):
>>>>
>>>> if you keep the default high quality choice,
>>>>
>>>> kdenlive adds "composite & transform" transitions that are based on 
>>>> Qt.
>>>>
>>>> So without gpl / qt module, MLT skips these transitions.
>>>>
>>>> Could you run your test switching to "no transparency"?
>>>>
>>>> (toolbar just above timeline)
>>>>
>>>> Thanks for you enthusiastic investigations :)
>>>>
>>>> Vincent
>>>>
>>>> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
>>>>
>>>> Hey guys, I have some more info.
>>>>
>>>> Hey Eugen, I have some more info.
>>>>
>>>> For this test I used mlt 6.11, successfully compiled by Dan 
>>>> Dennedy's build-melt.sh
>>>>
>>>> The test file that I am using is the 1080p version of Sintel.
>>>>
>>>> _https://durian.blender.org/download/_
>>>>
>>>> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 
>>>> 18.04
>>>>
>>>> In order to check melt and isolate the problem I simply rendered 
>>>> the first minute of the Sintel short film with the following command:
>>>>
>>>> (This is not the /bin/melt, but the script which launches it with 
>>>> the correct libs)
>>>>
>>>> /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv 
>>>> out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc 
>>>> preset=slow
>>>>
>>>> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization 
>>>> (NVENC): 80%] [Render Time: 20s]
>>>>
>>>> It obviously works perfectly.
>>>>
>>>> Now when I select this melt in the kdenlive environment, and also 
>>>> ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt 
>>>> folder, yields the following results when rendering the first 
>>>> minute of Sintel.
>>>>
>>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization 
>>>> (NVENC): 8%] [Render Time: 2m54s]
>>>>
>>>> Something in kdenlive breaks parallel processing, only allowing 1 
>>>> single core to be fully utilized.
>>>>
>>>> And I have tested every single version of kdenlive available on 
>>>> this earth.
>>>>
>>>> Every app image, including the refractoring version and every 
>>>> single ppa version, including stable, dev and master.
>>>>
>>>> Also generating and launching the render script from the terminal 
>>>> yields the same result.
>>>>
>>>> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>>>>
>>>> MELT="/home/frank/melt/20180724/melt"
>>>>
>>>> SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
>>>>
>>>> TARGET_0="file:///home/frank/Documents/untitled.mkv"
>>>>
>>>> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat 
>>>> - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
>>>>
>>>> $RENDERER $PARAMETERS_0
>>>>
>>>>
>>>>
>>>> I have also tested different kdenlive_render executables/libs with 
>>>> the same result.
>>>>
>>>> I should note, that using the kdenlive_multirender script in 
>>>> conjunction with the generated render script by kdenlive, while 
>>>> specifying 4 threads, the CPU uses 2 cores at 100%.
>>>>
>>>> _https://github.com/unfa/kdenlive-multirender_
>>>>
>>>> Now as I have described before, when I compile melt without 
>>>> enabling gpl, the 1 minute of Sintel renders perfectly again, with 
>>>> full utilization on both the CPU and GPU, but from within Kdenlive 
>>>> this time.
>>>>
>>>> I conclude that this problem is somehow caused by Kdenlive and 
>>>> related to qt, but I do not possess the knowhow to further analyze it.
>>>>
>>>> With the latest 18.08 Beta18 and the most recent QT version, 2 
>>>> cores instead of 1 are now being utilized at 100% with the NVENC 
>>>> profile and 100% on all 4 cores using the MP4 h264 profile.
>>>>
>>>> So this is 100% a QT issue with NVENC, but I need further insight 
>>>> from a professionals like yourselves.
>>>>
>>>> Sent with _ProtonMail_ <https://protonmail.com> Secure Email.
>>>>
>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>
>>>> On July 16, 2018 7:51 AM, johnar1 <johnar1 at protonmail.com> wrote:
>>>>
>>>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>>>>
>>>> I have successfully compiled mlt and ffmpeg with nvenc support 
>>>> using the official nvenc headers stripped from the Nvidia SDK.
>>>>
>>>> Rendering the first minute of the 1080p Sintel version, with 4 
>>>> threads specified and my nvenc profile, finishes in 10 seconds.
>>>>
>>>> Sintel can be downloaded here: 
>>>> _https://durian.blender.org/download/_ 
>>>> <https://durian.blender.org/download/[/url>
>>>>
>>>> Nvenc Profile: (compatible with recent mlt versions who are nvenc 
>>>> enabled by deafult)
>>>>
>>>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 
>>>> ab=384k
>>>>
>>>> Now here is the problem that I do not understand:
>>>>
>>>> Using the latest version of kdenlive from the kdenlive-master ppa 
>>>> combined with the newly compiled versions of ffmpeg and mlt works 
>>>> perfectly, but only under very specific circumstances.
>>>>
>>>> I have only been able to get rendering with nvenc to work properly 
>>>> when I use and open this specific kdenlive [b]save file[/b] which I 
>>>> made of the first minute of the Sintel short film with the Appimage 
>>>> Version of Kdenlive. After launching the ppa/installed version of 
>>>> kdenlive and opening this save file, rendering with nvenc works 
>>>> flawlessly.
>>>>
>>>> If I simply start a new project, adding the whole Sintel short film 
>>>> to the project bin, cutting the first minute and render it, nvenc 
>>>> simply does not work and the render time is tripled, despite having 
>>>> changed nothing else, including the nvenc render profile.
>>>>
>>>> If I create a save file of the first minute of Sintel with the 
>>>> installed version and open it on the Appimage version, nvenc does 
>>>> not work again.
>>>>
>>>> Conclusion: There must be something in this save file, maybe a 
>>>> parameter, additonal settings or any type of code not present in 
>>>> the default kdenlive project profiles, which enables NVENC.
>>>>
>>>> I would greatly appreciate it if we could find out the source of 
>>>> this problem together.
>>>>
>>>> Kdenlive Appimage Save File with which NVENC works:
>>>>
>>>> _https://pastebin.com/rzjR57DJ_
>>>>
>>>> PPA/Installed Version of Kdenlive created Save File which breaks 
>>>> NVENC:
>>>>
>>>> _https://pastebin.com/3uQ8sP0C_
>>>>
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180726/8a74552f/attachment-0001.html>

From johnar1 at protonmail.com  Thu Jul 26 17:17:52 2018
From: johnar1 at protonmail.com (johnar1)
Date: Thu, 26 Jul 2018 12:17:52 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <0e9086e8-1a5a-7c1c-e917-7885d298e398@kdenlive.org>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
 <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
 <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>
 <kh1MyUwt3vqLZKClvzue_xwmmPaM_GQ7SMLBrVUI9FOwVMXimxL9iHTNpfcqofsd0GoMG6bggcImQLfkhn41EI7TGUtUq5rPUzC7vKJvXS8=@protonmail.com>
 <0e9086e8-1a5a-7c1c-e917-7885d298e398@kdenlive.org>
Message-ID: <cgzwWIYNQZQEmvspbtuqW_YfwFamWYn2sPAQMQhAlFkTD2QTqecsWcmiKepnioHSwxbLjV-jtpJNUO5wSgQtKqDiJ57OMBfCCM8ee42dhI0=@protonmail.com>

I use 16.04 and 18.04 and I have found that using any kernel >4.15 severly breaks the nvidia-driver.

I am currently compiling 4.18 rc3 with the fixed modules to bypass the error caused with the driver but it's a pain.

NVENC is a nice feature, but if you use a lot of transitions, effects and title clips in kdenlive, then it's almost pointless, because gpu utilization is basically halted during these operations.

Tell me if you got it working.
And definitely try the Shotcut melt binary, it has given me even better nvenc performance than my self-compiled melt 6.11 from the latest git.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 26, 2018 10:47 AM, jb <jb at kdenlive.org> wrote:

> Le 26.07.18 à 10:02, johnar1 a écrit :
>
>> Hello Jean,
>>
>> yes that is correct, switching from High Quality compositing had a major impact on performance and I am not sure why.
>>
>> I can help you out getting NVENC to work.
>> What platform are you on?
>
> Thanks. My main issue is the NVidia driver, since I currently use an Ubuntu 16.04 based distro, and FFmpeg complains about my NVIDIA driver version < 390. I will upgrade my distro and give some feedback tomorrow.
>
> After that I guess a page on setting up nvenc would be nice on our wiki:
> https://community.kde.org/Kdenlive/Development/KF5
>
> Regards
> Jean-Baptiste
>
>> There are a couple things to be mindful of.
>>
>> .)After installing the graphics driver you need to genereate an xorg.conf
>> .)Install the NVENC Headers from here: https://github.com/lutris/ffmpeg-nvenc/issues/22
>> .)Use the correct NVENC parameter in your render profile, as the current one has been deprecated.
>> Here's my profile:
>> f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60 preset= slow g=120 bf=2
>>
>> .)You need to compile ffmpeg and mlt with the following flags:
>> ./configure --enable-nvenc --enable-cuvid --enable-nonfree
>>
>> Or if you don't want to compile yourself you can simply use the melt binary + libs from the most recent Shotcut build.
>> https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
>>
>> Instructions here:
>> https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
>>
>> This will get NVENC working 100%.
>> When you're done, you need to track the GPU utilization in the driver and make sure it is working. How many frames your GPU can push depends on the power of your CPU. I use the kdenlive_multirender  script to ensure 100% utilization on all cores and subsequently higher GPU utilization.
>> https://github.com/unfa/kdenlive-multirender
>>
>> Let's keep in touch!
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle [<jb at kdenlive.org>](mailto:jb at kdenlive.org) wrote:
>>
>>> On 25.07.2018 21:38, johnar1 wrote:
>>>
>>>> Dear Mr. Vincent Pinon,
>>>>
>>>> if that is in fact your real name, my first born son shall henceforth be known as Vincent.
>>>>
>>>> Your suggestion was spot on and according to my tests so far I believe it works.
>>>>
>>>> Here are my findings:
>>>>
>>>> Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC enabled,  Kdenlive 18.04 AppImage
>>>
>>> Hello Johnar,
>>>
>>> I am myself trying to setup a working nvenc environment and hope to make some more tests.
>>>
>>>> .)Track Composition - "None"
>>>> [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%] [Render Time: 15s]
>>>> I noticed however, that transitions such as for example Slide or Composite are rendered improperly, with certain interference patterns.
>>>>
>>>> After consulting the documentation, I realized that this should be fixed by disabling any surrounding empty tracks, but so far I have not been able to achieve that.
>>>>
>>>> .)Track Composition - "Preview"
>>>> [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%] [Render Time: 20s]
>>>>
>>>> I conclude that the best of both worlds comes into play with this option enabled.
>>>> Both the GPU and CPU are almost fully utilized, while it appears that transitions are rendered correctly.
>>>
>>> So if I understand correctly, rendering the same project with Track compositing set to "High Quality" has a major impact and you get this result:
>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization (NVENC): 8%] [Render Time: 2m54s]
>>>
>>> This seems strange to me since Kdenlive's "high quality" track compositing uses the qtblend transition that should automatically be bypassed when there is no transparency in the video. If you can confirm that and that this simple change in track compositing has such an impact this definitely has to be checked... Also, Dan recently fixed many of the "affine" transition issue, so it should give results similar to the "qtblend" transition but may be faster..
>>>
>>> Thanks for all your investigations, I hope to come back with more infos once I successfully achieve my setup.
>>>
>>> Best regards
>>> Jean-Baptiste
>>>
>>>> I will do more thorough testing and read any documentation available, as I absolutely want to understand what exactly these options do.
>>>>
>>>> I think it's a bit counterintutive to have "High Quality" enabled by default, which so heavily impacts performance, while in my opinion not making enough of an effort to alert the user to the extreme effects it may have on render times.
>>>>
>>>> I literally spent 72 hours straight, compiling every single version of melt and kdenlive, documenting and testing every possible compilation parameter variation, performance reviews with every available version of Ubuntu, corresponding kernels and nvidia drivers, and every remotely related kdenlive option or workarounds.
>>>>
>>>> This has  definitely shortened my life span by about 3 - 4 years.
>>>>
>>>> I would like to extend my gratitude to you, good sir.
>>>>
>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>>
>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>> On July 25, 2018 2:23 AM, Vincent Pinon [<vpinon at kde.org>](mailto:vpinon at kde.org) wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I don't know how precisely you do the job in kdenlive
>>>>>
>>>>> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>>>>>
>>>>> one thing I suspect is the track composition (automatic transparency):
>>>>>
>>>>> if you keep the default high quality choice,
>>>>>
>>>>> kdenlive adds "composite & transform" transitions that are based on Qt.
>>>>>
>>>>> So without gpl / qt module, MLT skips these transitions.
>>>>>
>>>>> Could you run your test switching to "no transparency"?
>>>>>
>>>>> (toolbar just above timeline)
>>>>>
>>>>> Thanks for you enthusiastic investigations :)
>>>>>
>>>>> Vincent
>>>>>
>>>>> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
>>>>>
>>>>> Hey guys, I have some more info.
>>>>>
>>>>> Hey Eugen, I have some more info.
>>>>>
>>>>> For this test I used mlt 6.11, successfully compiled by Dan Dennedy's build-melt.sh
>>>>>
>>>>> The test file that I am using is the 1080p version of Sintel.
>>>>>
>>>>> https://durian.blender.org/download/
>>>>>
>>>>> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04
>>>>>
>>>>> In order to check melt and isolate the problem I simply rendered the first minute of the Sintel short film with the following command:
>>>>>
>>>>> (This is not the /bin/melt, but the script which launches it with the correct libs)
>>>>>
>>>>> /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc preset=slow
>>>>>
>>>>> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization (NVENC): 80%] [Render Time: 20s]
>>>>>
>>>>> It obviously works perfectly.
>>>>>
>>>>> Now when I select this melt in the kdenlive environment, and also ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt folder, yields the following results when rendering the first minute of Sintel.
>>>>>
>>>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization (NVENC): 8%] [Render Time: 2m54s]
>>>>>
>>>>> Something in kdenlive breaks parallel processing, only allowing 1 single core to be fully utilized.
>>>>>
>>>>> And I have tested every single version of kdenlive available on this earth.
>>>>>
>>>>> Every app image, including the refractoring version and every single ppa version, including stable, dev and master.
>>>>>
>>>>> Also generating and launching the render script from the terminal yields the same result.
>>>>>
>>>>> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>>>>>
>>>>> MELT="/home/frank/melt/20180724/melt"
>>>>>
>>>>> SOURCE_0=
>>>>> "file:///home/frank/Documents/scripts/script001.sh.mlt"
>>>>>
>>>>> TARGET_0=
>>>>> "file:///home/frank/Documents/untitled.mkv"
>>>>>
>>>>> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
>>>>>
>>>>> $RENDERER $PARAMETERS_0
>>>>>
>>>>> I have also tested different kdenlive_render executables/libs with the same result.
>>>>>
>>>>> I should note, that using the kdenlive_multirender script in conjunction with the generated render script by kdenlive, while specifying 4 threads, the CPU uses 2 cores at 100%.
>>>>>
>>>>> https://github.com/unfa/kdenlive-multirender
>>>>>
>>>>> Now as I have described before, when I compile melt without enabling gpl, the 1 minute of Sintel renders perfectly again, with full utilization on both the CPU and GPU, but from within Kdenlive this time.
>>>>>
>>>>> I conclude that this problem is somehow caused by Kdenlive and related to qt, but I do not possess the knowhow to further analyze it.
>>>>>
>>>>> With the latest 18.08 Beta18 and the most recent QT version, 2 cores instead of 1 are now being utilized at 100% with the NVENC profile and 100% on all 4 cores using the MP4 h264 profile.
>>>>>
>>>>> So this is 100% a QT issue with NVENC, but I need further insight from a professionals like yourselves.
>>>>>
>>>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>>>
>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>
>>>>> On July 16, 2018 7:51 AM, johnar1 [<johnar1 at protonmail.com>](mailto:johnar1 at protonmail.com) wrote:
>>>>>
>>>>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>>>>>
>>>>> I have successfully compiled mlt and ffmpeg with nvenc support using the official nvenc headers stripped from the Nvidia SDK.
>>>>>
>>>>> Rendering the first minute of the 1080p Sintel version, with 4 threads specified and my nvenc profile, finishes in 10 seconds.
>>>>>
>>>>> Sintel can be downloaded here: [https://durian.blender.org/download/](https://durian.blender.org/download/[/url)
>>>>>
>>>>> Nvenc Profile: (compatible with recent mlt versions who are nvenc enabled by deafult)
>>>>>
>>>>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
>>>>>
>>>>> Now here is the problem that I do not understand:
>>>>>
>>>>> Using the latest version of kdenlive from the kdenlive-master ppa combined with the newly compiled versions of ffmpeg and mlt works perfectly, but only under very specific circumstances.
>>>>>
>>>>> I have only been able to get rendering with nvenc to work properly when I use and open this specific kdenlive [b]save file[/b] which I made of the first minute of the Sintel short film with the Appimage Version of Kdenlive. After launching the ppa/installed version of kdenlive and opening this save file, rendering with nvenc works flawlessly.
>>>>>
>>>>> If I simply start a new project, adding the whole Sintel short film to the project bin, cutting the first minute and render it, nvenc simply does not work and the render time is tripled, despite having changed nothing else, including the nvenc render profile.
>>>>>
>>>>> If I create a save file of the first minute of Sintel with the installed version and open it on the Appimage version, nvenc does not work again.
>>>>>
>>>>> Conclusion: There must be something in this save file, maybe a parameter, additonal settings or any type of code not present in the default kdenlive project profiles, which enables NVENC.
>>>>>
>>>>> I would greatly appreciate it if we could find out the source of this problem together.
>>>>>
>>>>> Kdenlive Appimage Save File with which NVENC works:
>>>>>
>>>>> https://pastebin.com/rzjR57DJ
>>>>>
>>>>> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
>>>>>
>>>>> https://pastebin.com/3uQ8sP0C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180726/0f3af42c/attachment-0001.html>

From informatica at actiu.net  Thu Jul 26 17:23:53 2018
From: informatica at actiu.net (Narcis Garcia)
Date: Thu, 26 Jul 2018 18:23:53 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <cgzwWIYNQZQEmvspbtuqW_YfwFamWYn2sPAQMQhAlFkTD2QTqecsWcmiKepnioHSwxbLjV-jtpJNUO5wSgQtKqDiJ57OMBfCCM8ee42dhI0=@protonmail.com>
Message-ID: <5b9e9a48-17f9-a3cd-47c0-0cd98fc37402@actiu.net>

Related to NV drivers, are you all talking about proprietary ones?


El 26/07/18 a les 18:17, johnar1 ha escrit:
> I use 16.04 and 18.04 and I have found that using any kernel >4.15
> severly breaks the nvidia-driver.
> 
> I am currently compiling 4.18 rc3 with the fixed modules to bypass the
> error caused with the driver but it's a pain.
> 
> NVENC is a nice feature, but if you use a lot of transitions, effects
> and title clips in kdenlive, then it's almost pointless, because gpu
> utilization is basically halted during these operations.
> 
> Tell me if you got it working.
> And definitely try the Shotcut melt binary, it has given me even better
> nvenc performance than my self-compiled melt 6.11 from the latest git.
> 
> 
> Sent with ProtonMail <https://protonmail.com> Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 26, 2018 10:47 AM, jb <jb at kdenlive.org> wrote:
> 
>> Le 26.07.18 à 10:02, johnar1 a écrit :
>>
>>> Hello Jean,
>>>
>>> yes that is correct, switching from High Quality compositing had a
>>> major impact on performance and I am not sure why.
>>>
>>> I can help you out getting NVENC to work.
>>> What platform are you on?
>>>
>> Thanks. My main issue is the NVidia driver, since I currently use an
>> Ubuntu 16.04 based distro, and FFmpeg complains about my NVIDIA driver
>> version < 390. I will upgrade my distro and give some feedback tomorrow.
>>
>> After that I guess a page on setting up nvenc would be nice on our wiki:
>> https://community.kde.org/Kdenlive/Development/KF5
>>
>> Regards
>> Jean-Baptiste
>>
>>> There are a couple things to be mindful of.
>>>
>>> .)After installing the graphics driver you need to genereate an xorg.conf
>>> .)Install the NVENC Headers from here:
>>> https://github.com/lutris/ffmpeg-nvenc/issues/22
>>> .)Use the correct NVENC parameter in your render profile, as the
>>> current one has been deprecated.
>>> Here's my profile:
>>> f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60 preset=
>>> slow g=120 bf=2
>>>
>>> .)You need to compile ffmpeg and mlt with the following flags:
>>> ./configure --enable-nvenc --enable-cuvid --enable-nonfree
>>>
>>> Or if you don't want to compile yourself you can simply use the melt
>>> binary + libs from the most recent Shotcut build.
>>> https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
>>>
>>> Instructions here:
>>> https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
>>>
>>> This will get NVENC working 100%.
>>> When you're done, you need to track the GPU utilization in the driver
>>> and make sure it is working. How many frames your GPU can push
>>> depends on the power of your CPU. I use the kdenlive_multirender 
>>> script to ensure 100% utilization on all cores and subsequently
>>> higher GPU utilization.
>>> https://github.com/unfa/kdenlive-multirender
>>>
>>> Let's keep in touch!
>>>
>>>
>>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle <jb at kdenlive.org> wrote:
>>>
>>>>
>>>> On 25.07.2018 21:38, johnar1 wrote:
>>>>> Dear Mr. Vincent Pinon,
>>>>>
>>>>> if that is in fact your real name, my first born son shall
>>>>> henceforth be known as Vincent.
>>>>>
>>>>> Your suggestion was spot on and according to my tests so far I
>>>>> believe it works.
>>>>>
>>>>> Here are my findings:
>>>>>
>>>>> Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC
>>>>> enabled,  Kdenlive 18.04 AppImage
>>>>
>>>> Hello Johnar,
>>>>
>>>> I am myself trying to setup a working nvenc environment and hope to
>>>> make some more tests.
>>>>
>>>>>
>>>>> .)Track Composition - "None"
>>>>> [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%]
>>>>> [Render Time: 15s]
>>>>> I noticed however, that transitions such as for example Slide or
>>>>> Composite are rendered improperly, with certain interference patterns.
>>>>>
>>>>> After consulting the documentation, I realized that this should be
>>>>> fixed by disabling any surrounding empty tracks, but so far I have
>>>>> not been able to achieve that.
>>>>>
>>>>> .)Track Composition - "Preview"
>>>>> [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%]
>>>>> [Render Time: 20s]
>>>>>
>>>>> I conclude that the best of both worlds comes into play with this
>>>>> option enabled.
>>>>> Both the GPU and CPU are almost fully utilized, while it appears
>>>>> that transitions are rendered correctly.
>>>>>
>>>> So if I understand correctly, rendering the same project with Track
>>>> compositing set to "High Quality" has a major impact and you get
>>>> this result:
>>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization
>>>> (NVENC): 8%] [Render Time: 2m54s]
>>>>
>>>> This seems strange to me since Kdenlive's "high quality" track
>>>> compositing uses the qtblend transition that should automatically be
>>>> bypassed when there is no transparency in the video. If you can
>>>> confirm that and that this simple change in track compositing has
>>>> such an impact this definitely has to be checked... Also, Dan
>>>> recently fixed many of the "affine" transition issue, so it should
>>>> give results similar to the "qtblend" transition but may be faster..
>>>>
>>>> Thanks for all your investigations, I hope to come back with more
>>>> infos once I successfully achieve my setup.
>>>>
>>>> Best regards
>>>> Jean-Baptiste
>>>>
>>>>
>>>>
>>>>> I will do more thorough testing and read any documentation
>>>>> available, as I absolutely want to understand what exactly these
>>>>> options do.
>>>>>
>>>>> I think it's a bit counterintutive to have "High Quality" enabled
>>>>> by default, which so heavily impacts performance, while in my
>>>>> opinion not making enough of an effort to alert the user to the
>>>>> extreme effects it may have on render times.
>>>>>
>>>>> I literally spent 72 hours straight, compiling every single version
>>>>> of melt and kdenlive, documenting and testing every possible
>>>>> compilation parameter variation, performance reviews with every
>>>>> available version of Ubuntu, corresponding kernels and nvidia
>>>>> drivers, and every remotely related kdenlive option or workarounds.
>>>>>
>>>>> This has  definitely shortened my life span by about 3 - 4 years.
>>>>>
>>>>> I would like to extend my gratitude to you, good sir.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>>>>
>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>> On July 25, 2018 2:23 AM, Vincent Pinon <vpinon at kde.org> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>  
>>>>>>
>>>>>> I don't know how precisely you do the job in kdenlive
>>>>>>
>>>>>> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>>>>>>
>>>>>>  
>>>>>>
>>>>>> one thing I suspect is the track composition (automatic transparency):
>>>>>>
>>>>>> if you keep the default high quality choice,
>>>>>>
>>>>>> kdenlive adds "composite & transform" transitions that are based
>>>>>> on Qt.
>>>>>>
>>>>>> So without gpl / qt module, MLT skips these transitions.
>>>>>>
>>>>>>  
>>>>>>
>>>>>> Could you run your test switching to "no transparency"?
>>>>>>
>>>>>> (toolbar just above timeline)
>>>>>>
>>>>>>  
>>>>>>
>>>>>> Thanks for you enthusiastic investigations :)
>>>>>>
>>>>>>  
>>>>>>
>>>>>> Vincent
>>>>>>
>>>>>>  
>>>>>>
>>>>>> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
>>>>>>
>>>>>> Hey guys, I have some more info.
>>>>>>
>>>>>>
>>>>>> Hey Eugen, I have some more info.
>>>>>>
>>>>>> For this test I used mlt 6.11, successfully compiled by Dan
>>>>>> Dennedy's build-melt.sh
>>>>>>
>>>>>> The test file that I am using is the 1080p version of Sintel.
>>>>>>
>>>>>> _https://durian.blender.org/download/_
>>>>>>
>>>>>> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform:
>>>>>> Kubuntu 18.04
>>>>>>
>>>>>> In order to check melt and isolate the problem I simply rendered
>>>>>> the first minute of the Sintel short film with the following command:
>>>>>>
>>>>>> (This is not the /bin/melt, but the script which launches it with
>>>>>> the correct libs)
>>>>>>
>>>>>>
>>>>>> /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv
>>>>>> out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc
>>>>>> preset=slow
>>>>>>
>>>>>> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization
>>>>>> (NVENC): 80%] [Render Time: 20s]
>>>>>>
>>>>>>
>>>>>> It obviously works perfectly.
>>>>>>
>>>>>>
>>>>>> Now when I select this melt in the kdenlive environment, and also
>>>>>> ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt
>>>>>> folder, yields the following results when rendering the first
>>>>>> minute of Sintel.
>>>>>>
>>>>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization
>>>>>> (NVENC): 8%] [Render Time: 2m54s]
>>>>>>
>>>>>> Something in kdenlive breaks parallel processing, only allowing 1
>>>>>> single core to be fully utilized.
>>>>>>
>>>>>> And I have tested every single version of kdenlive available on
>>>>>> this earth.
>>>>>>
>>>>>> Every app image, including the refractoring version and every
>>>>>> single ppa version, including stable, dev and master.
>>>>>>
>>>>>>
>>>>>> Also generating and launching the render script from the terminal
>>>>>> yields the same result.
>>>>>>
>>>>>> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>>>>>>
>>>>>>
>>>>>> MELT="/home/frank/melt/20180724/melt"
>>>>>>
>>>>>>
>>>>>> SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
>>>>>>
>>>>>>
>>>>>> TARGET_0="file:///home/frank/Documents/untitled.mkv"
>>>>>>
>>>>>>
>>>>>> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat
>>>>>> - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
>>>>>>
>>>>>>
>>>>>> $RENDERER $PARAMETERS_0
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have also tested different kdenlive_render executables/libs with
>>>>>> the same result.
>>>>>>
>>>>>> I should note, that using the kdenlive_multirender script in
>>>>>> conjunction with the generated render script by kdenlive, while
>>>>>> specifying 4 threads, the CPU uses 2 cores at 100%.
>>>>>>
>>>>>> _https://github.com/unfa/kdenlive-multirender_
>>>>>>
>>>>>>
>>>>>> Now as I have described before, when I compile melt without
>>>>>> enabling gpl, the 1 minute of Sintel renders perfectly again, with
>>>>>> full utilization on both the CPU and GPU, but from within Kdenlive
>>>>>> this time.
>>>>>>
>>>>>> I conclude that this problem is somehow caused by Kdenlive and
>>>>>> related to qt, but I do not possess the knowhow to further analyze it.
>>>>>>
>>>>>> With the latest 18.08 Beta18 and the most recent QT version, 2
>>>>>> cores instead of 1 are now being utilized at 100% with the NVENC
>>>>>> profile and 100% on all 4 cores using the MP4 h264 profile.
>>>>>>
>>>>>> So this is 100% a QT issue with NVENC, but I need further insight
>>>>>> from a professionals like yourselves.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sent with _ProtonMail_ <https://protonmail.com> Secure Email.
>>>>>>
>>>>>>
>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>
>>>>>> On July 16, 2018 7:51 AM, johnar1 <johnar1 at protonmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>>>>>>
>>>>>> I have successfully compiled mlt and ffmpeg with nvenc support
>>>>>> using the official nvenc headers stripped from the Nvidia SDK.
>>>>>>
>>>>>> Rendering the first minute of the 1080p Sintel version, with 4
>>>>>> threads specified and my nvenc profile, finishes in 10 seconds.
>>>>>>
>>>>>> Sintel can be downloaded here:
>>>>>> _https://durian.blender.org/download/_
>>>>>> <https://durian.blender.org/download/[/url>
>>>>>>
>>>>>> Nvenc Profile: (compatible with recent mlt versions who are nvenc
>>>>>> enabled by deafult)
>>>>>>
>>>>>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2
>>>>>> ab=384k
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now here is the problem that I do not understand:
>>>>>>
>>>>>> Using the latest version of kdenlive from the kdenlive-master ppa
>>>>>> combined with the newly compiled versions of ffmpeg and mlt works
>>>>>> perfectly, but only under very specific circumstances.
>>>>>>
>>>>>>
>>>>>> I have only been able to get rendering with nvenc to work properly
>>>>>> when I use and open this specific kdenlive [b]save file[/b] which
>>>>>> I made of the first minute of the Sintel short film with the
>>>>>> Appimage Version of Kdenlive. After launching the ppa/installed
>>>>>> version of kdenlive and opening this save file, rendering with
>>>>>> nvenc works flawlessly.
>>>>>>
>>>>>>
>>>>>> If I simply start a new project, adding the whole Sintel short
>>>>>> film to the project bin, cutting the first minute and render it,
>>>>>> nvenc simply does not work and the render time is tripled, despite
>>>>>> having changed nothing else, including the nvenc render profile.
>>>>>>
>>>>>>
>>>>>> If I create a save file of the first minute of Sintel with the
>>>>>> installed version and open it on the Appimage version, nvenc does
>>>>>> not work again.
>>>>>>
>>>>>>
>>>>>> Conclusion: There must be something in this save file, maybe a
>>>>>> parameter, additonal settings or any type of code not present in
>>>>>> the default kdenlive project profiles, which enables NVENC.
>>>>>>
>>>>>>
>>>>>> I would greatly appreciate it if we could find out the source of
>>>>>> this problem together.
>>>>>>
>>>>>>
>>>>>> Kdenlive Appimage Save File with which NVENC works:
>>>>>>
>>>>>> _https://pastebin.com/rzjR57DJ_
>>>>>>
>>>>>>
>>>>>> PPA/Installed Version of Kdenlive created Save File which breaks
>>>>>> NVENC:
>>>>>>
>>>>>> _https://pastebin.com/3uQ8sP0C_
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
> 

From johnar1 at protonmail.com  Thu Jul 26 22:52:28 2018
From: johnar1 at protonmail.com (johnar1)
Date: Thu, 26 Jul 2018 17:52:28 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <5b9e9a48-17f9-a3cd-47c0-0cd98fc37402@actiu.net>
References: <5b9e9a48-17f9-a3cd-47c0-0cd98fc37402@actiu.net>
Message-ID: <oar_F6QI7YZQKTa8FIao1bz1lEN6s568PIQKfceOCplOC1Gg-ClxMVUz-I0KeKCLYEtkYzSIJV8dFuEPfje4P9OChof0Pc4lJgfD6d3rvQI=@protonmail.com>

Hey Narcis,

I personally am referring to both the nvidia-390 and nvidia-396 package available at the Ubuntu Graphic's Team PPA and the equivalent .run files from the official nvidia.com website.

Kernel 4.17 and 4.18 both come with incompatible modules which cause the driver to immediately switch to 2D mode upon boot.


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 26, 2018 6:23 PM, Narcis Garcia <informatica at actiu.net> wrote:

> Related to NV drivers, are you all talking about proprietary ones?
>
> El 26/07/18 a les 18:17, johnar1 ha escrit:
>
> > I use 16.04 and 18.04 and I have found that using any kernel >4.15
> > severly breaks the nvidia-driver.
> > I am currently compiling 4.18 rc3 with the fixed modules to bypass the
> > error caused with the driver but it's a pain.
> > NVENC is a nice feature, but if you use a lot of transitions, effects
> > and title clips in kdenlive, then it's almost pointless, because gpu
> > utilization is basically halted during these operations.
> > Tell me if you got it working.
> > And definitely try the Shotcut melt binary, it has given me even better
> > nvenc performance than my self-compiled melt 6.11 from the latest git.
> > Sent with ProtonMail https://protonmail.com Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On July 26, 2018 10:47 AM, jb jb at kdenlive.org wrote:
> >
> > > Le 26.07.18 à 10:02, johnar1 a écrit :
> > >
> > > > Hello Jean,
> > > > yes that is correct, switching from High Quality compositing had a
> > > > major impact on performance and I am not sure why.
> > > > I can help you out getting NVENC to work.
> > > > What platform are you on?
> > >
> > > Thanks. My main issue is the NVidia driver, since I currently use an
> > > Ubuntu 16.04 based distro, and FFmpeg complains about my NVIDIA driver
> > > version < 390. I will upgrade my distro and give some feedback tomorrow.
> > > After that I guess a page on setting up nvenc would be nice on our wiki:
> > > https://community.kde.org/Kdenlive/Development/KF5
> > > Regards
> > > Jean-Baptiste
> > >
> > > > There are a couple things to be mindful of.
> > > > .)After installing the graphics driver you need to genereate an xorg.conf
> > > > .)Install the NVENC Headers from here:
> > > > https://github.com/lutris/ffmpeg-nvenc/issues/22
> > > > .)Use the correct NVENC parameter in your render profile, as the
> > > > current one has been deprecated.
> > > > Here's my profile:
> > > > f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60 preset=
> > > > slow g=120 bf=2
> > > > .)You need to compile ffmpeg and mlt with the following flags:
> > > > ./configure --enable-nvenc --enable-cuvid --enable-nonfree
> > > > Or if you don't want to compile yourself you can simply use the melt
> > > > binary + libs from the most recent Shotcut build.
> > > > https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
> > > > Instructions here:
> > > > https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
> > > > This will get NVENC working 100%.
> > > > When you're done, you need to track the GPU utilization in the driver
> > > > and make sure it is working. How many frames your GPU can push
> > > > depends on the power of your CPU. I use the kdenlive_multirender 
> > > > script to ensure 100% utilization on all cores and subsequently
> > > > higher GPU utilization.
> > > > https://github.com/unfa/kdenlive-multirender
> > > > Let's keep in touch!
> > > > Sent with ProtonMail https://protonmail.com Secure Email.
> > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle jb at kdenlive.org wrote:
> > > >
> > > > > On 25.07.2018 21:38, johnar1 wrote:
> > > > >
> > > > > > Dear Mr. Vincent Pinon,
> > > > > > if that is in fact your real name, my first born son shall
> > > > > > henceforth be known as Vincent.
> > > > > > Your suggestion was spot on and according to my tests so far I
> > > > > > believe it works.
> > > > > > Here are my findings:
> > > > > > Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC
> > > > > > enabled,  Kdenlive 18.04 AppImage
> > > > >
> > > > > Hello Johnar,
> > > > > I am myself trying to setup a working nvenc environment and hope to
> > > > > make some more tests.
> > > > >
> > > > > > .)Track Composition - "None"
> > > > > > [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%]
> > > > > > [Render Time: 15s]
> > > > > > I noticed however, that transitions such as for example Slide or
> > > > > > Composite are rendered improperly, with certain interference patterns.
> > > > > > After consulting the documentation, I realized that this should be
> > > > > > fixed by disabling any surrounding empty tracks, but so far I have
> > > > > > not been able to achieve that.
> > > > > > .)Track Composition - "Preview"
> > > > > > [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%]
> > > > > > [Render Time: 20s]
> > > > > > I conclude that the best of both worlds comes into play with this
> > > > > > option enabled.
> > > > > > Both the GPU and CPU are almost fully utilized, while it appears
> > > > > > that transitions are rendered correctly.
> > > > >
> > > > > So if I understand correctly, rendering the same project with Track
> > > > > compositing set to "High Quality" has a major impact and you get
> > > > > this result:
> > > > > [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization
> > > > > (NVENC): 8%] [Render Time: 2m54s]
> > > > > This seems strange to me since Kdenlive's "high quality" track
> > > > > compositing uses the qtblend transition that should automatically be
> > > > > bypassed when there is no transparency in the video. If you can
> > > > > confirm that and that this simple change in track compositing has
> > > > > such an impact this definitely has to be checked... Also, Dan
> > > > > recently fixed many of the "affine" transition issue, so it should
> > > > > give results similar to the "qtblend" transition but may be faster..
> > > > > Thanks for all your investigations, I hope to come back with more
> > > > > infos once I successfully achieve my setup.
> > > > > Best regards
> > > > > Jean-Baptiste
> > > > >
> > > > > > I will do more thorough testing and read any documentation
> > > > > > available, as I absolutely want to understand what exactly these
> > > > > > options do.
> > > > > > I think it's a bit counterintutive to have "High Quality" enabled
> > > > > > by default, which so heavily impacts performance, while in my
> > > > > > opinion not making enough of an effort to alert the user to the
> > > > > > extreme effects it may have on render times.
> > > > > > I literally spent 72 hours straight, compiling every single version
> > > > > > of melt and kdenlive, documenting and testing every possible
> > > > > > compilation parameter variation, performance reviews with every
> > > > > > available version of Ubuntu, corresponding kernels and nvidia
> > > > > > drivers, and every remotely related kdenlive option or workarounds.
> > > > > > This has  definitely shortened my life span by about 3 - 4 years.
> > > > > > I would like to extend my gratitude to you, good sir.
> > > > > > Sent with ProtonMail https://protonmail.com Secure Email.
> > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > > > On July 25, 2018 2:23 AM, Vincent Pinon vpinon at kde.org wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I don't know how precisely you do the job in kdenlive
> > > > > > > (you could share the .kdenlive, the .sh.mlt, a screenshot),
> > > > > > >
> > > > > > > one thing I suspect is the track composition (automatic transparency):
> > > > > > > if you keep the default high quality choice,
> > > > > > > kdenlive adds "composite & transform" transitions that are based
> > > > > > > on Qt.
> > > > > > > So without gpl / qt module, MLT skips these transitions.
> > > > > > >
> > > > > > > Could you run your test switching to "no transparency"?
> > > > > > > (toolbar just above timeline)
> > > > > > >
> > > > > > > Thanks for you enthusiastic investigations :)
> > > > > > >
> > > > > > > Vincent
> > > > > > >
> > > > > > > Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
> > > > > > > Hey guys, I have some more info.
> > > > > > > Hey Eugen, I have some more info.
> > > > > > > For this test I used mlt 6.11, successfully compiled by Dan
> > > > > > > Dennedy's build-melt.sh
> > > > > > > The test file that I am using is the 1080p version of Sintel.
> > > > > > > https://durian.blender.org/download/
> > > > > > > CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform:
> > > > > > > Kubuntu 18.04
> > > > > > > In order to check melt and isolate the problem I simply rendered
> > > > > > > the first minute of the Sintel short film with the following command:
> > > > > > > (This is not the /bin/melt, but the script which launches it with
> > > > > > > the correct libs)
> > > > > > > /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv
> > > > > > > out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc
> > > > > > > preset=slow
> > > > > > > [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization
> > > > > > > (NVENC): 80%] [Render Time: 20s]
> > > > > > > It obviously works perfectly.
> > > > > > > Now when I select this melt in the kdenlive environment, and also
> > > > > > > ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt
> > > > > > > folder, yields the following results when rendering the first
> > > > > > > minute of Sintel.
> > > > > > > [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization
> > > > > > > (NVENC): 8%] [Render Time: 2m54s]
> > > > > > > Something in kdenlive breaks parallel processing, only allowing 1
> > > > > > > single core to be fully utilized.
> > > > > > > And I have tested every single version of kdenlive available on
> > > > > > > this earth.
> > > > > > > Every app image, including the refractoring version and every
> > > > > > > single ppa version, including stable, dev and master.
> > > > > > > Also generating and launching the render script from the terminal
> > > > > > > yields the same result.
> > > > > > > RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
> > > > > > > MELT="/home/frank/melt/20180724/melt"
> > > > > > > SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
> > > > > > > TARGET_0="file:///home/frank/Documents/untitled.mkv"
> > > > > > > PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat
> > > > > > >
> > > > > > > -   $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
> > > > > > >
> > > > > > > $RENDERER $PARAMETERS_0
> > > > > > > I have also tested different kdenlive_render executables/libs with
> > > > > > > the same result.
> > > > > > > I should note, that using the kdenlive_multirender script in
> > > > > > > conjunction with the generated render script by kdenlive, while
> > > > > > > specifying 4 threads, the CPU uses 2 cores at 100%.
> > > > > > > https://github.com/unfa/kdenlive-multirender
> > > > > > > Now as I have described before, when I compile melt without
> > > > > > > enabling gpl, the 1 minute of Sintel renders perfectly again, with
> > > > > > > full utilization on both the CPU and GPU, but from within Kdenlive
> > > > > > > this time.
> > > > > > > I conclude that this problem is somehow caused by Kdenlive and
> > > > > > > related to qt, but I do not possess the knowhow to further analyze it.
> > > > > > > With the latest 18.08 Beta18 and the most recent QT version, 2
> > > > > > > cores instead of 1 are now being utilized at 100% with the NVENC
> > > > > > > profile and 100% on all 4 cores using the MP4 h264 profile.
> > > > > > > So this is 100% a QT issue with NVENC, but I need further insight
> > > > > > > from a professionals like yourselves.
> > > > > > > Sent with ProtonMail https://protonmail.com Secure Email.
> > > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > > > > On July 16, 2018 7:51 AM, johnar1 johnar1 at protonmail.com wrote:
> > > > > > > System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
> > > > > > > I have successfully compiled mlt and ffmpeg with nvenc support
> > > > > > > using the official nvenc headers stripped from the Nvidia SDK.
> > > > > > > Rendering the first minute of the 1080p Sintel version, with 4
> > > > > > > threads specified and my nvenc profile, finishes in 10 seconds.
> > > > > > > Sintel can be downloaded here:
> > > > > > > https://durian.blender.org/download/
> > > > > > > https://durian.blender.org/download/[/url
> > > > > > > Nvenc Profile: (compatible with recent mlt versions who are nvenc
> > > > > > > enabled by deafult)
> > > > > > > f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2
> > > > > > > ab=384k
> > > > > > > Now here is the problem that I do not understand:
> > > > > > > Using the latest version of kdenlive from the kdenlive-master ppa
> > > > > > > combined with the newly compiled versions of ffmpeg and mlt works
> > > > > > > perfectly, but only under very specific circumstances.
> > > > > > > I have only been able to get rendering with nvenc to work properly
> > > > > > > when I use and open this specific kdenlive [b]save file[/b] which
> > > > > > > I made of the first minute of the Sintel short film with the
> > > > > > > Appimage Version of Kdenlive. After launching the ppa/installed
> > > > > > > version of kdenlive and opening this save file, rendering with
> > > > > > > nvenc works flawlessly.
> > > > > > > If I simply start a new project, adding the whole Sintel short
> > > > > > > film to the project bin, cutting the first minute and render it,
> > > > > > > nvenc simply does not work and the render time is tripled, despite
> > > > > > > having changed nothing else, including the nvenc render profile.
> > > > > > > If I create a save file of the first minute of Sintel with the
> > > > > > > installed version and open it on the Appimage version, nvenc does
> > > > > > > not work again.
> > > > > > > Conclusion: There must be something in this save file, maybe a
> > > > > > > parameter, additonal settings or any type of code not present in
> > > > > > > the default kdenlive project profiles, which enables NVENC.
> > > > > > > I would greatly appreciate it if we could find out the source of
> > > > > > > this problem together.
> > > > > > > Kdenlive Appimage Save File with which NVENC works:
> > > > > > > https://pastebin.com/rzjR57DJ
> > > > > > > PPA/Installed Version of Kdenlive created Save File which breaks
> > > > > > > NVENC:
> > > > > > > https://pastebin.com/3uQ8sP0C



From informatica at actiu.net  Fri Jul 27 07:59:30 2018
From: informatica at actiu.net (Narcis Garcia)
Date: Fri, 27 Jul 2018 08:59:30 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <oar_F6QI7YZQKTa8FIao1bz1lEN6s568PIQKfceOCplOC1Gg-ClxMVUz-I0KeKCLYEtkYzSIJV8dFuEPfje4P9OChof0Pc4lJgfD6d3rvQI=@protonmail.com>
Message-ID: <48c3ddc5-0e7e-24e2-98d1-637535622b3c@actiu.net>

Sorry for my ignorance but,
Isn't possible to use NVENC method with FOSS drivers?


El 26/07/18 a les 23:52, johnar1 ha escrit:
> Hey Narcis,
> 
> I personally am referring to both the nvidia-390 and nvidia-396 package available at the Ubuntu Graphic's Team PPA and the equivalent .run files from the official nvidia.com website.
> 
> Kernel 4.17 and 4.18 both come with incompatible modules which cause the driver to immediately switch to 2D mode upon boot.
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 26, 2018 6:23 PM, Narcis Garcia <informatica at actiu.net> wrote:
> 
>> Related to NV drivers, are you all talking about proprietary ones?
>>
>> El 26/07/18 a les 18:17, johnar1 ha escrit:
>>
>>> I use 16.04 and 18.04 and I have found that using any kernel >4.15
>>> severly breaks the nvidia-driver.
>>> I am currently compiling 4.18 rc3 with the fixed modules to bypass the
>>> error caused with the driver but it's a pain.
>>> NVENC is a nice feature, but if you use a lot of transitions, effects
>>> and title clips in kdenlive, then it's almost pointless, because gpu
>>> utilization is basically halted during these operations.
>>> Tell me if you got it working.
>>> And definitely try the Shotcut melt binary, it has given me even better
>>> nvenc performance than my self-compiled melt 6.11 from the latest git.
>>> Sent with ProtonMail https://protonmail.com Secure Email.
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On July 26, 2018 10:47 AM, jb jb at kdenlive.org wrote:
>>>
>>>> Le 26.07.18 à 10:02, johnar1 a écrit :
>>>>
>>>>> Hello Jean,
>>>>> yes that is correct, switching from High Quality compositing had a
>>>>> major impact on performance and I am not sure why.
>>>>> I can help you out getting NVENC to work.
>>>>> What platform are you on?
>>>>
>>>> Thanks. My main issue is the NVidia driver, since I currently use an
>>>> Ubuntu 16.04 based distro, and FFmpeg complains about my NVIDIA driver
>>>> version < 390. I will upgrade my distro and give some feedback tomorrow.
>>>> After that I guess a page on setting up nvenc would be nice on our wiki:
>>>> https://community.kde.org/Kdenlive/Development/KF5
>>>> Regards
>>>> Jean-Baptiste
>>>>
>>>>> There are a couple things to be mindful of.
>>>>> .)After installing the graphics driver you need to genereate an xorg.conf
>>>>> .)Install the NVENC Headers from here:
>>>>> https://github.com/lutris/ffmpeg-nvenc/issues/22
>>>>> .)Use the correct NVENC parameter in your render profile, as the
>>>>> current one has been deprecated.
>>>>> Here's my profile:
>>>>> f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60 preset=
>>>>> slow g=120 bf=2
>>>>> .)You need to compile ffmpeg and mlt with the following flags:
>>>>> ./configure --enable-nvenc --enable-cuvid --enable-nonfree
>>>>> Or if you don't want to compile yourself you can simply use the melt
>>>>> binary + libs from the most recent Shotcut build.
>>>>> https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
>>>>> Instructions here:
>>>>> https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
>>>>> This will get NVENC working 100%.
>>>>> When you're done, you need to track the GPU utilization in the driver
>>>>> and make sure it is working. How many frames your GPU can push
>>>>> depends on the power of your CPU. I use the kdenlive_multirender 
>>>>> script to ensure 100% utilization on all cores and subsequently
>>>>> higher GPU utilization.
>>>>> https://github.com/unfa/kdenlive-multirender
>>>>> Let's keep in touch!
>>>>> Sent with ProtonMail https://protonmail.com Secure Email.
>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>> On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle jb at kdenlive.org wrote:
>>>>>
>>>>>> On 25.07.2018 21:38, johnar1 wrote:
>>>>>>
>>>>>>> Dear Mr. Vincent Pinon,
>>>>>>> if that is in fact your real name, my first born son shall
>>>>>>> henceforth be known as Vincent.
>>>>>>> Your suggestion was spot on and according to my tests so far I
>>>>>>> believe it works.
>>>>>>> Here are my findings:
>>>>>>> Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC
>>>>>>> enabled,  Kdenlive 18.04 AppImage
>>>>>>
>>>>>> Hello Johnar,
>>>>>> I am myself trying to setup a working nvenc environment and hope to
>>>>>> make some more tests.
>>>>>>
>>>>>>> .)Track Composition - "None"
>>>>>>> [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%]
>>>>>>> [Render Time: 15s]
>>>>>>> I noticed however, that transitions such as for example Slide or
>>>>>>> Composite are rendered improperly, with certain interference patterns.
>>>>>>> After consulting the documentation, I realized that this should be
>>>>>>> fixed by disabling any surrounding empty tracks, but so far I have
>>>>>>> not been able to achieve that.
>>>>>>> .)Track Composition - "Preview"
>>>>>>> [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%]
>>>>>>> [Render Time: 20s]
>>>>>>> I conclude that the best of both worlds comes into play with this
>>>>>>> option enabled.
>>>>>>> Both the GPU and CPU are almost fully utilized, while it appears
>>>>>>> that transitions are rendered correctly.
>>>>>>
>>>>>> So if I understand correctly, rendering the same project with Track
>>>>>> compositing set to "High Quality" has a major impact and you get
>>>>>> this result:
>>>>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization
>>>>>> (NVENC): 8%] [Render Time: 2m54s]
>>>>>> This seems strange to me since Kdenlive's "high quality" track
>>>>>> compositing uses the qtblend transition that should automatically be
>>>>>> bypassed when there is no transparency in the video. If you can
>>>>>> confirm that and that this simple change in track compositing has
>>>>>> such an impact this definitely has to be checked... Also, Dan
>>>>>> recently fixed many of the "affine" transition issue, so it should
>>>>>> give results similar to the "qtblend" transition but may be faster..
>>>>>> Thanks for all your investigations, I hope to come back with more
>>>>>> infos once I successfully achieve my setup.
>>>>>> Best regards
>>>>>> Jean-Baptiste
>>>>>>
>>>>>>> I will do more thorough testing and read any documentation
>>>>>>> available, as I absolutely want to understand what exactly these
>>>>>>> options do.
>>>>>>> I think it's a bit counterintutive to have "High Quality" enabled
>>>>>>> by default, which so heavily impacts performance, while in my
>>>>>>> opinion not making enough of an effort to alert the user to the
>>>>>>> extreme effects it may have on render times.
>>>>>>> I literally spent 72 hours straight, compiling every single version
>>>>>>> of melt and kdenlive, documenting and testing every possible
>>>>>>> compilation parameter variation, performance reviews with every
>>>>>>> available version of Ubuntu, corresponding kernels and nvidia
>>>>>>> drivers, and every remotely related kdenlive option or workarounds.
>>>>>>> This has  definitely shortened my life span by about 3 - 4 years.
>>>>>>> I would like to extend my gratitude to you, good sir.
>>>>>>> Sent with ProtonMail https://protonmail.com Secure Email.
>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>> On July 25, 2018 2:23 AM, Vincent Pinon vpinon at kde.org wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I don't know how precisely you do the job in kdenlive
>>>>>>>> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>>>>>>>>
>>>>>>>> one thing I suspect is the track composition (automatic transparency):
>>>>>>>> if you keep the default high quality choice,
>>>>>>>> kdenlive adds "composite & transform" transitions that are based
>>>>>>>> on Qt.
>>>>>>>> So without gpl / qt module, MLT skips these transitions.
>>>>>>>>
>>>>>>>> Could you run your test switching to "no transparency"?
>>>>>>>> (toolbar just above timeline)
>>>>>>>>
>>>>>>>> Thanks for you enthusiastic investigations :)
>>>>>>>>
>>>>>>>> Vincent
>>>>>>>>
>>>>>>>> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
>>>>>>>> Hey guys, I have some more info.
>>>>>>>> Hey Eugen, I have some more info.
>>>>>>>> For this test I used mlt 6.11, successfully compiled by Dan
>>>>>>>> Dennedy's build-melt.sh
>>>>>>>> The test file that I am using is the 1080p version of Sintel.
>>>>>>>> https://durian.blender.org/download/
>>>>>>>> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform:
>>>>>>>> Kubuntu 18.04
>>>>>>>> In order to check melt and isolate the problem I simply rendered
>>>>>>>> the first minute of the Sintel short film with the following command:
>>>>>>>> (This is not the /bin/melt, but the script which launches it with
>>>>>>>> the correct libs)
>>>>>>>> /home/frank/melt/20180724/melt -profile atsc_1080p_60 sintel.mkv
>>>>>>>> out=3600 -consumer avformat:result-60.mp4 f=mp4 vcodec=h264_nvenc
>>>>>>>> preset=slow
>>>>>>>> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine Utilization
>>>>>>>> (NVENC): 80%] [Render Time: 20s]
>>>>>>>> It obviously works perfectly.
>>>>>>>> Now when I select this melt in the kdenlive environment, and also
>>>>>>>> ffmpeg, ffplay, ffprobe and the profiles path from Dan's melt
>>>>>>>> folder, yields the following results when rendering the first
>>>>>>>> minute of Sintel.
>>>>>>>> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine Utilization
>>>>>>>> (NVENC): 8%] [Render Time: 2m54s]
>>>>>>>> Something in kdenlive breaks parallel processing, only allowing 1
>>>>>>>> single core to be fully utilized.
>>>>>>>> And I have tested every single version of kdenlive available on
>>>>>>>> this earth.
>>>>>>>> Every app image, including the refractoring version and every
>>>>>>>> single ppa version, including stable, dev and master.
>>>>>>>> Also generating and launching the render script from the terminal
>>>>>>>> yields the same result.
>>>>>>>> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>>>>>>>> MELT="/home/frank/melt/20180724/melt"
>>>>>>>> SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
>>>>>>>> TARGET_0="file:///home/frank/Documents/untitled.mkv"
>>>>>>>> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 avformat
>>>>>>>>
>>>>>>>> -   $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 real_time=-1"
>>>>>>>>
>>>>>>>> $RENDERER $PARAMETERS_0
>>>>>>>> I have also tested different kdenlive_render executables/libs with
>>>>>>>> the same result.
>>>>>>>> I should note, that using the kdenlive_multirender script in
>>>>>>>> conjunction with the generated render script by kdenlive, while
>>>>>>>> specifying 4 threads, the CPU uses 2 cores at 100%.
>>>>>>>> https://github.com/unfa/kdenlive-multirender
>>>>>>>> Now as I have described before, when I compile melt without
>>>>>>>> enabling gpl, the 1 minute of Sintel renders perfectly again, with
>>>>>>>> full utilization on both the CPU and GPU, but from within Kdenlive
>>>>>>>> this time.
>>>>>>>> I conclude that this problem is somehow caused by Kdenlive and
>>>>>>>> related to qt, but I do not possess the knowhow to further analyze it.
>>>>>>>> With the latest 18.08 Beta18 and the most recent QT version, 2
>>>>>>>> cores instead of 1 are now being utilized at 100% with the NVENC
>>>>>>>> profile and 100% on all 4 cores using the MP4 h264 profile.
>>>>>>>> So this is 100% a QT issue with NVENC, but I need further insight
>>>>>>>> from a professionals like yourselves.
>>>>>>>> Sent with ProtonMail https://protonmail.com Secure Email.
>>>>>>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>>>>>>> On July 16, 2018 7:51 AM, johnar1 johnar1 at protonmail.com wrote:
>>>>>>>> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
>>>>>>>> I have successfully compiled mlt and ffmpeg with nvenc support
>>>>>>>> using the official nvenc headers stripped from the Nvidia SDK.
>>>>>>>> Rendering the first minute of the 1080p Sintel version, with 4
>>>>>>>> threads specified and my nvenc profile, finishes in 10 seconds.
>>>>>>>> Sintel can be downloaded here:
>>>>>>>> https://durian.blender.org/download/
>>>>>>>> https://durian.blender.org/download/[/url
>>>>>>>> Nvenc Profile: (compatible with recent mlt versions who are nvenc
>>>>>>>> enabled by deafult)
>>>>>>>> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2
>>>>>>>> ab=384k
>>>>>>>> Now here is the problem that I do not understand:
>>>>>>>> Using the latest version of kdenlive from the kdenlive-master ppa
>>>>>>>> combined with the newly compiled versions of ffmpeg and mlt works
>>>>>>>> perfectly, but only under very specific circumstances.
>>>>>>>> I have only been able to get rendering with nvenc to work properly
>>>>>>>> when I use and open this specific kdenlive [b]save file[/b] which
>>>>>>>> I made of the first minute of the Sintel short film with the
>>>>>>>> Appimage Version of Kdenlive. After launching the ppa/installed
>>>>>>>> version of kdenlive and opening this save file, rendering with
>>>>>>>> nvenc works flawlessly.
>>>>>>>> If I simply start a new project, adding the whole Sintel short
>>>>>>>> film to the project bin, cutting the first minute and render it,
>>>>>>>> nvenc simply does not work and the render time is tripled, despite
>>>>>>>> having changed nothing else, including the nvenc render profile.
>>>>>>>> If I create a save file of the first minute of Sintel with the
>>>>>>>> installed version and open it on the Appimage version, nvenc does
>>>>>>>> not work again.
>>>>>>>> Conclusion: There must be something in this save file, maybe a
>>>>>>>> parameter, additonal settings or any type of code not present in
>>>>>>>> the default kdenlive project profiles, which enables NVENC.
>>>>>>>> I would greatly appreciate it if we could find out the source of
>>>>>>>> this problem together.
>>>>>>>> Kdenlive Appimage Save File with which NVENC works:
>>>>>>>> https://pastebin.com/rzjR57DJ
>>>>>>>> PPA/Installed Version of Kdenlive created Save File which breaks
>>>>>>>> NVENC:
>>>>>>>> https://pastebin.com/3uQ8sP0C
> 
> 

From jb at kdenlive.org  Fri Jul 27 12:09:56 2018
From: jb at kdenlive.org (Jean-Baptiste Mardelle)
Date: Fri, 27 Jul 2018 13:09:56 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 =?iso-8859-1?Q?Problem?=
In-Reply-To: <48c3ddc5-0e7e-24e2-98d1-637535622b3c@actiu.net>
References: <48c3ddc5-0e7e-24e2-98d1-637535622b3c@actiu.net>
Message-ID: <5fe4debd-94c6-40ce-9727-c1e1035f39d8@kdenlive.org>

On Friday, July 27, 2018 8:59:30 AM CEST, Narcis Garcia wrote:
> Sorry for my ignorance but,
> Isn't possible to use NVENC method with FOSS drivers?

Unfortunately not. Some hardware acceleration is available on the nouveau 
driver:
https://nouveau.freedesktop.org/wiki/VideoAcceleration/

But it seems limited to some older generation graphic cards, and only with 
the vaapi acceleration which I am not sure we can use in MLT...

Regards
Jean-Baptiste


> El 26/07/18 a les 23:52, johnar1 ha escrit:
>> Hey Narcis,
>> 
>> I personally am referring to both the nvidia-390 and 
>> nvidia-396 package available at the Ubuntu Graphic's Team PPA 
>> and the equivalent .run files from the official nvidia.com 
>> website.
>> 
>> Kernel 4.17 and 4.18 both come with incompatible modules which 
>> cause the driver to immediately switch to 2D mode upon boot.
>> 
>> 
>> Sent with ProtonMail Secure Email.
>> 
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ ...
>
>


From jb at kdenlive.org  Fri Jul 27 13:29:50 2018
From: jb at kdenlive.org (Jean-Baptiste Mardelle)
Date: Fri, 27 Jul 2018 14:29:50 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 =?iso-8859-1?Q?Problem?=
In-Reply-To: <cgzwWIYNQZQEmvspbtuqW_YfwFamWYn2sPAQMQhAlFkTD2QTqecsWcmiKepnioHSwxbLjV-jtpJNUO5wSgQtKqDiJ57OMBfCCM8ee42dhI0=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
 <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
 <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>
 <kh1MyUwt3vqLZKClvzue_xwmmPaM_GQ7SMLBrVUI9FOwVMXimxL9iHTNpfcqofsd0GoMG6bggcImQLfkhn41EI7TGUtUq5rPUzC7vKJvXS8=@protonmail.com>
 <0e9086e8-1a5a-7c1c-e917-7885d298e398@kdenlive.org>
 <cgzwWIYNQZQEmvspbtuqW_YfwFamWYn2sPAQMQhAlFkTD2QTqecsWcmiKepnioHSwxbLjV-jtpJNUO5wSgQtKqDiJ57OMBfCCM8ee42dhI0=@protonmail.com>
Message-ID: <11185f96-e3fc-455e-9f96-436f8dc78a43@kdenlive.org>

On Thursday, July 26, 2018 6:17:52 PM CEST, johnar1 wrote:
> I use 16.04 and 18.04 and I have found that using any kernel 
> >4.15 severly breaks the nvidia-driver.
>
> I am currently compiling 4.18 rc3 with the fixed modules to 
> bypass the error caused with the driver but it's a pain.
>
> NVENC is a nice feature, but if you use a lot of transitions, 
> effects and title clips in kdenlive, then it's almost pointless, 
> because gpu utilization is basically halted during these 
> operations.
>
> Tell me if you got it working.
> And definitely try the Shotcut melt binary, it has given me 
> even better nvenc performance than my self-compiled melt 6.11 
> from the latest git.


Hello!

So I got nvenc working and have some interesting results. First, regarding 
the slowdown with the high quality track compositing:

The transition used for tracks high quality compositing (qtblend) has some 
code to detect if a compositing is necessary. For example, if the video on 
the top track uses a pixel format that does not use alpha, like RGB, we 
don't try to perform the composition, and directly return the top frame as 
a result. There are several checks to make sure we don't need to do the 
compositing, and one of them is a check of the aspect ratio. If the frames 
aspect ratio don't match, we do perform the compositing. Useful for example 
if you put a small image on a track above a video track, you usually want 
to be able to see the video in the area not covered by the image.

This is the reason for the slowdown on rendering with high quality, because 
your sample sintel movie is in fact a 1920x818 video, with a DAR (display 
aspect ratio) of 960:409.

So it does not match the 1920x1080, 16:9 DAR project property, and so we do 
perform the compositing, slowing down the process. Not sure what is the 
best way to handle this, but we can probably find a solution to prevent 
compositing in some cases.

Now regarding the nvenc performance, I also got some very encouraging 
results. Using a 1920x1080 mp4 sample clip of 46 seconds, I got the 
following results with my GTX 1050 TI card (all tests use the default "high 
quality" track compositing):

Test 1: No effects, one clip in timeline. Render times:
libxvid: 1m30s
nvenc:   7s (!!!)

Test 2: one clip in timeline, with lift/gamma/gain color correction. Render 
times:
libxvid: 1m29s
nvenc:   36s

Test 3: one clip in timeline, with sepia effect. Render times:
libxvid: 1m29s
nvenc:   8s

(sepia filter works in yuv422, while lift/gamma/gain requires an rgb 
colorspace, which explains the performance diff).

Test 4: 1 exta image clip composited over the video. Render times:
libxvid: 1m37s
nvenc:   1m02s

So even with effects and transitions we still get a comfortable time gain. 
It will also be interesting to integrate this in Kdenlive's internal uses, 
like timeline preview and creating proxy clips which will make everything 
faster (I successfully created I frame only clips with nvenc so we can get 
a frame accurate seeking). I also made some tests with the scale_npp 
rescale filter: 

ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -i Sintel.2010.1080p.mkv -filter:v 
scale_npp=320:200 -vcodec h264_nvenc result.mp4

transcoding (using ffmpeg only) the full movie to 320x200 proxy:
using nvenc and scale_npp: 43s.
Using nvenc the normal ffmpeg's scale filter: 1m18s
Using libxvid and normal scale filter: 1m31s
Compared to no resize:
using nvenc without resizing: 1m11s
using libxvid without resizing: 6m08s


So that means we can should be able to create proxy clips twice as fast, 
and timeline preview probably also.

The only sad part is that it requires the NVIDIA proprietary drivers, but 
maybe FFmpeg's other free hwaccel methods will be usable as well in the 
future. If anybody wants to test other hardware, you are welcome.

I will anyways integrate these nvenc speedups in the big december 2018 
refactoring release.

Best regards

Jean-Baptiste

> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 26, 2018 10:47 AM, jb <jb at kdenlive.org> wrote:
>
> Le 26.07.18 à 10:02, johnar1 a écrit :
>
> Hello Jean,
>
> yes that is correct, switching from High Quality compositing 
> had a major impact on performance and I am not sure why.
>
> I can help you out getting NVENC to work.
> What platform are you on?
>
> Thanks. My main issue is the NVidia driver, since I currently 
> use an Ubuntu 16.04 based distro, and FFmpeg complains about my 
> NVIDIA driver version < 390. I will upgrade my distro and give 
> some feedback tomorrow.
>
> After that I guess a page on setting up nvenc would be nice on our wiki:
> https://community.kde.org/Kdenlive/Development/KF5
>
> Regards
> Jean-Baptiste
>
> There are a couple things to be mindful of.
>
> .)After installing the graphics driver you need to genereate an xorg.conf
> .)Install the NVENC Headers from here: 
> https://github.com/lutris/ffmpeg-nvenc/issues/22
> .)Use the correct NVENC parameter in your render profile, as 
> the current one has been deprecated.
> Here's my profile:
> f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60 
> preset= slow g=120 bf=2
>
> .)You need to compile ffmpeg and mlt with the following flags:
> ./configure --enable-nvenc --enable-cuvid --enable-nonfree
>
> Or if you don't want to compile yourself you can simply use the 
> melt binary + libs from the most recent Shotcut build.
> https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
>
> Instructions here:
> https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
>
> This will get NVENC working 100%.
> When you're done, you need to track the GPU utilization in the 
> driver and make sure it is working. How many frames your GPU can 
> push depends on the power of your CPU. I use the 
> kdenlive_multirender  script to ensure 100% utilization on all 
> cores and subsequently higher GPU utilization.
> https://github.com/unfa/kdenlive-multirender
>
> Let's keep in touch!
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle <jb at kdenlive.org> wrote:
>
>
> On 25.07.2018 21:38, johnar1 wrote:
> Dear Mr. Vincent Pinon,
>
> if that is in fact your real name, my first born son shall 
> henceforth be known as Vincent.
>
> Your suggestion was spot on and according to my tests so far I 
> believe it works.
>
> Here are my findings:
>
> Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC 
> enabled,  Kdenlive 18.04 AppImage
>
> Hello Johnar,
>
> I am myself trying to setup a working nvenc environment and 
> hope to make some more tests.
>
>
> .)Track Composition - "None" 
> [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%] 
> [Render Time: 15s]
> I noticed however, that transitions such as for example Slide 
> or Composite are rendered improperly, with certain interference 
> patterns.
>
> After consulting the documentation, I realized that this should 
> be fixed by disabling any surrounding empty tracks, but so far I 
> have not been able to achieve that.
>
> .)Track Composition - "Preview"
> [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%] 
> [Render Time: 20s]
>
> I conclude that the best of both worlds comes into play with 
> this option enabled.
> Both the GPU and CPU are almost fully utilized, while it 
> appears that transitions are rendered correctly.
>
> So if I understand correctly, rendering the same project with 
> Track compositing set to "High Quality" has a major impact and 
> you get this result:
> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine 
> Utilization (NVENC): 8%] [Render Time: 2m54s]
>
> This seems strange to me since Kdenlive's "high quality" track 
> compositing uses the qtblend transition that should 
> automatically be bypassed when there is no transparency in the 
> video. If you can confirm that and that this simple change in 
> track compositing has such an impact this definitely has to be 
> checked... Also, Dan recently fixed many of the "affine" 
> transition issue, so it should give results similar to the 
> "qtblend" transition but may be faster..
>
> Thanks for all your investigations, I hope to come back with 
> more infos once I successfully achieve my setup.
>
> Best regards
> Jean-Baptiste
>
>
>
> I will do more thorough testing and read any documentation 
> available, as I absolutely want to understand what exactly these 
> options do.
>
> I think it's a bit counterintutive to have "High Quality" 
> enabled by default, which so heavily impacts performance, while 
> in my opinion not making enough of an effort to alert the user 
> to the extreme effects it may have on render times.
>
> I literally spent 72 hours straight, compiling every single 
> version of melt and kdenlive, documenting and testing every 
> possible compilation parameter variation, performance reviews 
> with every available version of Ubuntu, corresponding kernels 
> and nvidia drivers, and every remotely related kdenlive option 
> or workarounds.
>
> This has  definitely shortened my life span by about 3 - 4 years.
>
> I would like to extend my gratitude to you, good sir.
>
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 25, 2018 2:23 AM, Vincent Pinon <vpinon at kde.org> wrote:
>
> Hello,
>  
> I don't know how precisely you do the job in kdenlive
> (you could share the .kdenlive, the .sh.mlt, a screenshot),
>  
> one thing I suspect is the track composition (automatic transparency):
> if you keep the default high quality choice,
> kdenlive adds "composite & transform" transitions that are based on Qt.
> So without gpl / qt module, MLT skips these transitions.
>  
> Could you run your test switching to "no transparency"?
> (toolbar just above timeline)
>  
> Thanks for you enthusiastic investigations :)
>  
> Vincent
>  
> Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
> Hey guys, I have some more info.
>
> Hey Eugen, I have some more info.
> For this test I used mlt 6.11, successfully compiled by Dan 
> Dennedy's build-melt.sh
>
> The test file that I am using is the 1080p version of Sintel.
> https://durian.blender.org/download/
> CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04
>
> In order to check melt and isolate the problem I simply 
> rendered the first minute of the Sintel short film with the 
> following command:
> (This is not the /bin/melt, but the script which launches it 
> with the correct libs)
>
> /home/frank/melt/20180724/melt -profile atsc_1080p_60 
> sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4 
> vcodec=h264_nvenc preset=slow
> [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine 
> Utilization (NVENC): 80%] [Render Time: 20s]
>
>
> It obviously works perfectly.
>
>
> Now when I select this melt in the kdenlive environment, and 
> also ffmpeg, ffplay, ffprobe and the profiles path from Dan's 
> melt folder, yields the following results when rendering the 
> first minute of Sintel.
> [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine 
> Utilization (NVENC): 8%] [Render Time: 2m54s]
> Something in kdenlive breaks parallel processing, only allowing 
> 1 single core to be fully utilized.
> And I have tested every single version of kdenlive available on this earth.
> Every app image, including the refractoring version and every 
> single ppa version, including stable, dev and master.
>
>
> Also generating and launching the render script from the 
> terminal yields the same result.
>
> RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
>
>
> MELT="/home/frank/melt/20180724/melt"
>
>
> SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
>
>
> TARGET_0="file:///home/frank/Documents/untitled.mkv"
>
>
> PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60 
> avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4 
> real_time=-1"
>
>
> $RENDERER $PARAMETERS_0
>
>
>
>
>
> I have also tested different kdenlive_render executables/libs 
> with the same result.
>
> I should note, that using the kdenlive_multirender script in 
> conjunction with the generated render script by kdenlive, while 
> specifying 4 threads, the CPU uses 2 cores at 100%.
> https://github.com/unfa/kdenlive-multirender
>
> Now as I have described before, when I compile melt without 
> enabling gpl, the 1 minute of Sintel renders perfectly again, 
> with full utilization on both the CPU and GPU, but from within 
> Kdenlive this time.
>
> I conclude that this problem is somehow caused by Kdenlive and 
> related to qt, but I do not possess the knowhow to further 
> analyze it.
>
> With the latest 18.08 Beta18 and the most recent QT version, 2 
> cores instead of 1 are now being utilized at 100% with the NVENC 
> profile and 100% on all 4 cores using the MP4 h264 profile.
>
> So this is 100% a QT issue with NVENC, but I need further 
> insight from a professionals like yourselves.
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 16, 2018 7:51 AM, johnar1 <johnar1 at protonmail.com> wrote:
>
>
>
> System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
> I have successfully compiled mlt and ffmpeg with nvenc support 
> using the official nvenc headers stripped from the Nvidia SDK.
> Rendering the first minute of the 1080p Sintel version, with 4 
> threads specified and my nvenc profile, finishes in 10 seconds.
> Sintel can be downloaded here: https://durian.blender.org/download/
> Nvenc Profile: (compatible with recent mlt versions who are 
> nvenc enabled by deafult)
> f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
>
>
> Now here is the problem that I do not understand:
> Using the latest version of kdenlive from the kdenlive-master 
> ppa combined with the newly compiled versions of ffmpeg and mlt 
> works perfectly, but only under very specific circumstances.
>
> I have only been able to get rendering with nvenc to work 
> properly when I use and open this specific kdenlive [b]save 
> file[/b] which I made of the first minute of the Sintel short 
> film with the Appimage Version of Kdenlive. After launching the 
> ppa/installed version of kdenlive and opening this save file, 
> rendering with nvenc works flawlessly.
>
> If I simply start a new project, adding the whole Sintel short 
> film to the project bin, cutting the first minute and render it, 
> nvenc simply does not work and the render time is tripled, 
> despite having changed nothing else, including the nvenc render 
> profile.
>
> If I create a save file of the first minute of Sintel with the 
> installed version and open it on the Appimage version, nvenc 
> does not work again.
>
> Conclusion: There must be something in this save file, maybe a 
> parameter, additonal settings or any type of code not present in 
> the default kdenlive project profiles, which enables NVENC.
>
> I would greatly appreciate it if we could find out the source 
> of this problem together.
>
> Kdenlive Appimage Save File with which NVENC works:
> https://pastebin.com/rzjR57DJ
>
> PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
> https://pastebin.com/3uQ8sP0C
>
>
>
>
>
>
>


From jdd at dodin.org  Fri Jul 27 17:05:28 2018
From: jdd at dodin.org (jdd at dodin.org)
Date: Fri, 27 Jul 2018 18:05:28 +0200
Subject: rotate a video
Message-ID: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>

Hello

I hope it's here than I can have help to use kdenlive, else please 
direct me to the right place :-)

I'm a long time french user of kdenlive. Right now I have to fix an 
orientation error of one camera, not horizontal.

to fix this, I presently use the effect "rotate and shear" and rotate on 
x axis around -20

but then  black triangle are seen on any 4 corners:

https://www.cjoint.com/doc/18_07/HGBp1zZHxLh_Screenshot-20180727-175223.png

When I do the same with Digikam (for example) with photos, there is an 
option "keep the larger image" that keeps the larger size possible 
excluding the black area.

Is there a way to do the same on kdenlive? I can't make the zoom or crop
give the right result

thanks
jdd


-- 
http://dodin.org

From andres.tello at gmail.com  Fri Jul 27 17:27:12 2018
From: andres.tello at gmail.com (andres tello)
Date: Fri, 27 Jul 2018 11:27:12 -0500
Subject: rotate a video
In-Reply-To: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
References: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
Message-ID: <CAArVfJdwUbvJoO0PFRXpUCGeKJZCMNSM6YPLREO+dGCjd1d4aw@mail.gmail.com>

the background is solid? you just could add a title with that background to
cover the 'empty' spaces that got black renderd...
 the other thing I would to, is export the frame, take it to gimp, correct
the corners, cut the inside, save it as transparent png and place it at
video1, just add a little composiete opacity to blend it nicely...

 And lastly, I would do a litle % of zoom, but you said you can't do it...


On Fri, Jul 27, 2018 at 11:05 AM jdd at dodin.org <jdd at dodin.org> wrote:

> Hello
>
> I hope it's here than I can have help to use kdenlive, else please
> direct me to the right place :-)
>
> I'm a long time french user of kdenlive. Right now I have to fix an
> orientation error of one camera, not horizontal.
>
> to fix this, I presently use the effect "rotate and shear" and rotate on
> x axis around -20
>
> but then  black triangle are seen on any 4 corners:
>
> https://www.cjoint.com/doc/18_07/HGBp1zZHxLh_Screenshot-20180727-175223.png
>
> When I do the same with Digikam (for example) with photos, there is an
> option "keep the larger image" that keeps the larger size possible
> excluding the black area.
>
> Is there a way to do the same on kdenlive? I can't make the zoom or crop
> give the right result
>
> thanks
> jdd
>
>
> --
> http://dodin.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180727/f2aec66e/attachment-0001.html>

From jdd at dodin.org  Fri Jul 27 17:28:59 2018
From: jdd at dodin.org (jdd at dodin.org)
Date: Fri, 27 Jul 2018 18:28:59 +0200
Subject: rotate a video
In-Reply-To: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
References: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
Message-ID: <d22d4efd-25cc-55e4-6aa8-d7b45545a505@dodin.org>

Le 27/07/2018 à 18:05, jdd at dodin.org a écrit :

> Is there a way to do the same on kdenlive? I can't make the zoom or crop
> give the right result
> 
I may have found an at least partial solution.
with x rotate = -20, add at the bottom of the rotate and shear effect 
x=-40, y=-40, w=2000 h=1160 (gives a 107% zoom). Eventually use - and | 
to center ,(but this may change the given numbers)

not easy to find the correct numbers, automatic calculus would be nice :-)

thanks
jdd


-- 
http://dodin.org

From jdd at dodin.org  Fri Jul 27 17:44:50 2018
From: jdd at dodin.org (jdd at dodin.org)
Date: Fri, 27 Jul 2018 18:44:50 +0200
Subject: rotate a video
In-Reply-To: <CAArVfJdwUbvJoO0PFRXpUCGeKJZCMNSM6YPLREO+dGCjd1d4aw@mail.gmail.com>
References: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
 <CAArVfJdwUbvJoO0PFRXpUCGeKJZCMNSM6YPLREO+dGCjd1d4aw@mail.gmail.com>
Message-ID: <3b009bce-ed50-666e-f679-65895ac6d0b2@dodin.org>

Le 27/07/2018 à 18:27, andres tello a écrit :
> the background is solid?

the video is full screen, no (normally no) background :-(

on most of the clips the borders are very dark, so I didn't notice the 
problem at first :-(

>   And lastly, I would do a litle % of zoom, but you said you can't do it...
> 

I don't find easy, in kdenlive, to zoom out, a good idea could be to add 
a second resizing frame inside the image :-)

thanks
jdd


-- 
http://dodin.org

From jdd at dodin.org  Fri Jul 27 18:28:39 2018
From: jdd at dodin.org (jdd at dodin.org)
Date: Fri, 27 Jul 2018 19:28:39 +0200
Subject: rotate a video
In-Reply-To: <CAArVfJdmLt5_e7=mQQAbAPALiceFd6aYTCASZoQQjyhqMvvEgA@mail.gmail.com>
References: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
 <CAArVfJdwUbvJoO0PFRXpUCGeKJZCMNSM6YPLREO+dGCjd1d4aw@mail.gmail.com>
 <3b009bce-ed50-666e-f679-65895ac6d0b2@dodin.org>
 <CAArVfJdmLt5_e7=mQQAbAPALiceFd6aYTCASZoQQjyhqMvvEgA@mail.gmail.com>
Message-ID: <e4d5234d-3c77-6381-a642-794d6fe06748@dodin.org>

Le 27/07/2018 à 19:07, andres tello a écrit :

> Zoom... you can have a zoom in or zoom out in 1% granularity...barely 
> noticable, just to cover your dark corners...
> 

yes, but one have to test each numerical value typing them by hand (not 
even up or down arrow), and that after having defined the key frames

I expected to be able to do it with the mouse, but it's easy to zoom in 
but not to zoom out (the corners are out of reach)

I think I found once a way to have the image smaller, but can't find it 
right now :-(

thanks
jdd


-- 
http://dodin.org

From informatica at actiu.net  Fri Jul 27 19:30:40 2018
From: informatica at actiu.net (Narcis Garcia)
Date: Fri, 27 Jul 2018 20:30:40 +0200
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <5fe4debd-94c6-40ce-9727-c1e1035f39d8@kdenlive.org>
Message-ID: <9767a5d4-95a9-5f5c-b4d1-5d6028cc9500@actiu.net>

Sad to see that, due to development of drivers is low level programming,
most of efforts go to the use of proprietary stuff.


El 27/07/18 a les 13:09, Jean-Baptiste Mardelle ha escrit:
> On Friday, July 27, 2018 8:59:30 AM CEST, Narcis Garcia wrote:
>> Sorry for my ignorance but,
>> Isn't possible to use NVENC method with FOSS drivers?
> 
> Unfortunately not. Some hardware acceleration is available on the
> nouveau driver:
> https://nouveau.freedesktop.org/wiki/VideoAcceleration/
> 
> But it seems limited to some older generation graphic cards, and only
> with the vaapi acceleration which I am not sure we can use in MLT...
> 
> Regards
> Jean-Baptiste
> 
> 
>> El 26/07/18 a les 23:52, johnar1 ha escrit:
>>> Hey Narcis,
>>>
>>> I personally am referring to both the nvidia-390 and nvidia-396
>>> package available at the Ubuntu Graphic's Team PPA and the equivalent
>>> .run files from the official nvidia.com website.
>>>
>>> Kernel 4.17 and 4.18 both come with incompatible modules which cause
>>> the driver to immediately switch to 2D mode upon boot.
>>>
>>>
>>> Sent with ProtonMail Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ ...
>>
>>
> 

From andres.tello at gmail.com  Sat Jul 28 00:02:17 2018
From: andres.tello at gmail.com (andres tello)
Date: Fri, 27 Jul 2018 18:02:17 -0500
Subject: rotate a video
In-Reply-To: <e4d5234d-3c77-6381-a642-794d6fe06748@dodin.org>
References: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
 <CAArVfJdwUbvJoO0PFRXpUCGeKJZCMNSM6YPLREO+dGCjd1d4aw@mail.gmail.com>
 <3b009bce-ed50-666e-f679-65895ac6d0b2@dodin.org>
 <CAArVfJdmLt5_e7=mQQAbAPALiceFd6aYTCASZoQQjyhqMvvEgA@mail.gmail.com>
 <e4d5234d-3c77-6381-a642-794d6fe06748@dodin.org>
Message-ID: <CAArVfJdtPKdkJuG=QgUndOXQaMHiw6jR=+_HaAeQLqZD4NBtKg@mail.gmail.com>

weird... bcause I just do it with the mouse...
really !


On Fri, Jul 27, 2018 at 12:28 PM jdd at dodin.org <jdd at dodin.org> wrote:

> Le 27/07/2018 à 19:07, andres tello a écrit :
>
> > Zoom... you can have a zoom in or zoom out in 1% granularity...barely
> > noticable, just to cover your dark corners...
> >
>
> yes, but one have to test each numerical value typing them by hand (not
> even up or down arrow), and that after having defined the key frames
>
> I expected to be able to do it with the mouse, but it's easy to zoom in
> but not to zoom out (the corners are out of reach)
>
> I think I found once a way to have the image smaller, but can't find it
> right now :-(
>
> thanks
> jdd
>
>
> --
> http://dodin.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180727/fb63a681/attachment.html>

From jdd at dodin.org  Sat Jul 28 10:03:36 2018
From: jdd at dodin.org (jdd at dodin.org)
Date: Sat, 28 Jul 2018 11:03:36 +0200
Subject: rotate a video
In-Reply-To: <CAArVfJdtPKdkJuG=QgUndOXQaMHiw6jR=+_HaAeQLqZD4NBtKg@mail.gmail.com>
References: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
 <CAArVfJdwUbvJoO0PFRXpUCGeKJZCMNSM6YPLREO+dGCjd1d4aw@mail.gmail.com>
 <3b009bce-ed50-666e-f679-65895ac6d0b2@dodin.org>
 <CAArVfJdmLt5_e7=mQQAbAPALiceFd6aYTCASZoQQjyhqMvvEgA@mail.gmail.com>
 <e4d5234d-3c77-6381-a642-794d6fe06748@dodin.org>
 <CAArVfJdtPKdkJuG=QgUndOXQaMHiw6jR=+_HaAeQLqZD4NBtKg@mail.gmail.com>
Message-ID: <649d6feb-b09f-dcd9-8217-009fc671a8c0@dodin.org>

Le 28/07/2018 à 01:02, andres tello a écrit :
> weird... bcause I just do it with the mouse...
> really !
> 
> 


when you zoom out, the handles are soon out of reach. I still think than 
a second handle rectangle at mid place from the center would be very 
nice (and may be not too difficult to code), but I found the monitor 
zoom feature. If the (small) image goes through the list you will see:

one have to find on the right of monitor commands a small icon for an 
other menu for zooming tools. Then one can zoom in the monitor and have 
the handles at hand :-)

thanks
jdd


-- 
http://dodin.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: web_IMG_20180728_104754583.jpg
Type: image/jpeg
Size: 98190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180728/f3b31eab/attachment-0001.jpg>

From johnar1 at protonmail.com  Sat Jul 28 16:02:13 2018
From: johnar1 at protonmail.com (johnar1)
Date: Sat, 28 Jul 2018 11:02:13 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <11185f96-e3fc-455e-9f96-436f8dc78a43@kdenlive.org>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
 <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
 <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>
 <kh1MyUwt3vqLZKClvzue_xwmmPaM_GQ7SMLBrVUI9FOwVMXimxL9iHTNpfcqofsd0GoMG6bggcImQLfkhn41EI7TGUtUq5rPUzC7vKJvXS8=@protonmail.com>
 <0e9086e8-1a5a-7c1c-e917-7885d298e398@kdenlive.org>
 <cgzwWIYNQZQEmvspbtuqW_YfwFamWYn2sPAQMQhAlFkTD2QTqecsWcmiKepnioHSwxbLjV-jtpJNUO5wSgQtKqDiJ57OMBfCCM8ee42dhI0=@protonmail.com>
 <11185f96-e3fc-455e-9f96-436f8dc78a43@kdenlive.org>
Message-ID: <q5vCE89ZxIwHGGxd1af7No-H-L3TUFZY_cW73VBCYOKHScqRjzlrkkUkejYtrvY-6AiilhE81wLoKTDwqA8TB_PBwufMGGVSB9yZLN_qCpE=@protonmail.com>

Hey Jean!

So you are saying, that the reason why there is very low CPU usage and no NVENC usage with the Sintel clip, is because it's not exactly 1920x1080p resolution?
I shall test different clips then.

What version of kdenlive are you using?
Also what versions of ffmpeg, ffprobe, ffplay, and melt?

Some info on your CPU, general hardware setup and platform would be nice too.

I would like to link up with you and run tests on the same footage.

I have a 1050TI lying around here and a 6600K, let's compare our results in a similar testing environment.

Just reinstalled Lubuntu 18.04 and working on the kdenlive 18.08 refractoring release.

Let's use this as a sample: https://peach.blender.org/download/

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 27, 2018 2:29 PM, Jean-Baptiste Mardelle <jb at kdenlive.org> wrote:

> On Thursday, July 26, 2018 6:17:52 PM CEST, johnar1 wrote:
>
> > I use 16.04 and 18.04 and I have found that using any kernel
> >
> > > 4.15 severly breaks the nvidia-driver.
> >
> > I am currently compiling 4.18 rc3 with the fixed modules to
> > bypass the error caused with the driver but it's a pain.
> > NVENC is a nice feature, but if you use a lot of transitions,
> > effects and title clips in kdenlive, then it's almost pointless,
> > because gpu utilization is basically halted during these
> > operations.
> > Tell me if you got it working.
> > And definitely try the Shotcut melt binary, it has given me
> > even better nvenc performance than my self-compiled melt 6.11
> > from the latest git.
>
> Hello!
>
> So I got nvenc working and have some interesting results. First, regarding
> the slowdown with the high quality track compositing:
>
> The transition used for tracks high quality compositing (qtblend) has some
> code to detect if a compositing is necessary. For example, if the video on
> the top track uses a pixel format that does not use alpha, like RGB, we
> don't try to perform the composition, and directly return the top frame as
> a result. There are several checks to make sure we don't need to do the
> compositing, and one of them is a check of the aspect ratio. If the frames
> aspect ratio don't match, we do perform the compositing. Useful for example
> if you put a small image on a track above a video track, you usually want
> to be able to see the video in the area not covered by the image.
>
> This is the reason for the slowdown on rendering with high quality, because
> your sample sintel movie is in fact a 1920x818 video, with a DAR (display
> aspect ratio) of 960:409.
>
> So it does not match the 1920x1080, 16:9 DAR project property, and so we do
> perform the compositing, slowing down the process. Not sure what is the
> best way to handle this, but we can probably find a solution to prevent
> compositing in some cases.
>
> Now regarding the nvenc performance, I also got some very encouraging
> results. Using a 1920x1080 mp4 sample clip of 46 seconds, I got the
> following results with my GTX 1050 TI card (all tests use the default "high
> quality" track compositing):
>
> Test 1: No effects, one clip in timeline. Render times:
> libxvid: 1m30s
> nvenc: 7s (!!!)
>
> Test 2: one clip in timeline, with lift/gamma/gain color correction. Render
> times:
> libxvid: 1m29s
> nvenc: 36s
>
> Test 3: one clip in timeline, with sepia effect. Render times:
> libxvid: 1m29s
> nvenc: 8s
>
> (sepia filter works in yuv422, while lift/gamma/gain requires an rgb
> colorspace, which explains the performance diff).
>
> Test 4: 1 exta image clip composited over the video. Render times:
> libxvid: 1m37s
> nvenc: 1m02s
>
> So even with effects and transitions we still get a comfortable time gain.
> It will also be interesting to integrate this in Kdenlive's internal uses,
> like timeline preview and creating proxy clips which will make everything
> faster (I successfully created I frame only clips with nvenc so we can get
> a frame accurate seeking). I also made some tests with the scale_npp
> rescale filter:
>
> ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -i Sintel.2010.1080p.mkv -filter:v
> scale_npp=320:200 -vcodec h264_nvenc result.mp4
>
> transcoding (using ffmpeg only) the full movie to 320x200 proxy:
> using nvenc and scale_npp: 43s.
> Using nvenc the normal ffmpeg's scale filter: 1m18s
> Using libxvid and normal scale filter: 1m31s
> Compared to no resize:
> using nvenc without resizing: 1m11s
> using libxvid without resizing: 6m08s
>
> So that means we can should be able to create proxy clips twice as fast,
> and timeline preview probably also.
>
> The only sad part is that it requires the NVIDIA proprietary drivers, but
> maybe FFmpeg's other free hwaccel methods will be usable as well in the
> future. If anybody wants to test other hardware, you are welcome.
>
> I will anyways integrate these nvenc speedups in the big december 2018
> refactoring release.
>
> Best regards
>
> Jean-Baptiste
>
> > Sent with ProtonMail Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On July 26, 2018 10:47 AM, jb jb at kdenlive.org wrote:
> > Le 26.07.18 à 10:02, johnar1 a écrit :
> > Hello Jean,
> > yes that is correct, switching from High Quality compositing
> > had a major impact on performance and I am not sure why.
> > I can help you out getting NVENC to work.
> > What platform are you on?
> > Thanks. My main issue is the NVidia driver, since I currently
> > use an Ubuntu 16.04 based distro, and FFmpeg complains about my
> > NVIDIA driver version < 390. I will upgrade my distro and give
> > some feedback tomorrow.
> > After that I guess a page on setting up nvenc would be nice on our wiki:
> > https://community.kde.org/Kdenlive/Development/KF5
> > Regards
> > Jean-Baptiste
> > There are a couple things to be mindful of.
> > .)After installing the graphics driver you need to genereate an xorg.conf
> > .)Install the NVENC Headers from here:
> > https://github.com/lutris/ffmpeg-nvenc/issues/22
> > .)Use the correct NVENC parameter in your render profile, as
> > the current one has been deprecated.
> > Here's my profile:
> > f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60
> > preset= slow g=120 bf=2
> > .)You need to compile ffmpeg and mlt with the following flags:
> > ./configure --enable-nvenc --enable-cuvid --enable-nonfree
> > Or if you don't want to compile yourself you can simply use the
> > melt binary + libs from the most recent Shotcut build.
> > https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
> > Instructions here:
> > https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
> > This will get NVENC working 100%.
> > When you're done, you need to track the GPU utilization in the
> > driver and make sure it is working. How many frames your GPU can
> > push depends on the power of your CPU. I use the
> > kdenlive_multirender script to ensure 100% utilization on all
> > cores and subsequently higher GPU utilization.
> > https://github.com/unfa/kdenlive-multirender
> > Let's keep in touch!
> > Sent with ProtonMail Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle jb at kdenlive.org wrote:
> > On 25.07.2018 21:38, johnar1 wrote:
> > Dear Mr. Vincent Pinon,
> > if that is in fact your real name, my first born son shall
> > henceforth be known as Vincent.
> > Your suggestion was spot on and according to my tests so far I
> > believe it works.
> > Here are my findings:
> > Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC
> > enabled, Kdenlive 18.04 AppImage
> > Hello Johnar,
> > I am myself trying to setup a working nvenc environment and
> > hope to make some more tests.
> > .)Track Composition - "None"
> > [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%]
> > [Render Time: 15s]
> > I noticed however, that transitions such as for example Slide
> > or Composite are rendered improperly, with certain interference
> > patterns.
> > After consulting the documentation, I realized that this should
> > be fixed by disabling any surrounding empty tracks, but so far I
> > have not been able to achieve that.
> > .)Track Composition - "Preview"
> > [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%]
> > [Render Time: 20s]
> > I conclude that the best of both worlds comes into play with
> > this option enabled.
> > Both the GPU and CPU are almost fully utilized, while it
> > appears that transitions are rendered correctly.
> > So if I understand correctly, rendering the same project with
> > Track compositing set to "High Quality" has a major impact and
> > you get this result:
> > [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine
> > Utilization (NVENC): 8%] [Render Time: 2m54s]
> > This seems strange to me since Kdenlive's "high quality" track
> > compositing uses the qtblend transition that should
> > automatically be bypassed when there is no transparency in the
> > video. If you can confirm that and that this simple change in
> > track compositing has such an impact this definitely has to be
> > checked... Also, Dan recently fixed many of the "affine"
> > transition issue, so it should give results similar to the
> > "qtblend" transition but may be faster..
> > Thanks for all your investigations, I hope to come back with
> > more infos once I successfully achieve my setup.
> > Best regards
> > Jean-Baptiste
> > I will do more thorough testing and read any documentation
> > available, as I absolutely want to understand what exactly these
> > options do.
> > I think it's a bit counterintutive to have "High Quality"
> > enabled by default, which so heavily impacts performance, while
> > in my opinion not making enough of an effort to alert the user
> > to the extreme effects it may have on render times.
> > I literally spent 72 hours straight, compiling every single
> > version of melt and kdenlive, documenting and testing every
> > possible compilation parameter variation, performance reviews
> > with every available version of Ubuntu, corresponding kernels
> > and nvidia drivers, and every remotely related kdenlive option
> > or workarounds.
> > This has definitely shortened my life span by about 3 - 4 years.
> > I would like to extend my gratitude to you, good sir.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On July 25, 2018 2:23 AM, Vincent Pinon vpinon at kde.org wrote:
> > Hello,
> > I don't know how precisely you do the job in kdenlive
> > (you could share the .kdenlive, the .sh.mlt, a screenshot),
> > one thing I suspect is the track composition (automatic transparency):
> > if you keep the default high quality choice,
> > kdenlive adds "composite & transform" transitions that are based on Qt.
> > So without gpl / qt module, MLT skips these transitions.
> > Could you run your test switching to "no transparency"?
> > (toolbar just above timeline)
> > Thanks for you enthusiastic investigations :)
> > Vincent
> > Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
> > Hey guys, I have some more info.
> > Hey Eugen, I have some more info.
> > For this test I used mlt 6.11, successfully compiled by Dan
> > Dennedy's build-melt.sh
> > The test file that I am using is the 1080p version of Sintel.
> > https://durian.blender.org/download/
> > CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04
> > In order to check melt and isolate the problem I simply
> > rendered the first minute of the Sintel short film with the
> > following command:
> > (This is not the /bin/melt, but the script which launches it
> > with the correct libs)
> > /home/frank/melt/20180724/melt -profile atsc_1080p_60
> > sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4
> > vcodec=h264_nvenc preset=slow
> > [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine
> > Utilization (NVENC): 80%] [Render Time: 20s]
> > It obviously works perfectly.
> > Now when I select this melt in the kdenlive environment, and
> > also ffmpeg, ffplay, ffprobe and the profiles path from Dan's
> > melt folder, yields the following results when rendering the
> > first minute of Sintel.
> > [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine
> > Utilization (NVENC): 8%] [Render Time: 2m54s]
> > Something in kdenlive breaks parallel processing, only allowing
> > 1 single core to be fully utilized.
> > And I have tested every single version of kdenlive available on this earth.
> > Every app image, including the refractoring version and every
> > single ppa version, including stable, dev and master.
> > Also generating and launching the render script from the
> > terminal yields the same result.
> > RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
> > MELT="/home/frank/melt/20180724/melt"
> > SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
> > TARGET_0="file:///home/frank/Documents/untitled.mkv"
> > PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60
> > avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4
> > real_time=-1"
> > $RENDERER $PARAMETERS_0
> > I have also tested different kdenlive_render executables/libs
> > with the same result.
> > I should note, that using the kdenlive_multirender script in
> > conjunction with the generated render script by kdenlive, while
> > specifying 4 threads, the CPU uses 2 cores at 100%.
> > https://github.com/unfa/kdenlive-multirender
> > Now as I have described before, when I compile melt without
> > enabling gpl, the 1 minute of Sintel renders perfectly again,
> > with full utilization on both the CPU and GPU, but from within
> > Kdenlive this time.
> > I conclude that this problem is somehow caused by Kdenlive and
> > related to qt, but I do not possess the knowhow to further
> > analyze it.
> > With the latest 18.08 Beta18 and the most recent QT version, 2
> > cores instead of 1 are now being utilized at 100% with the NVENC
> > profile and 100% on all 4 cores using the MP4 h264 profile.
> > So this is 100% a QT issue with NVENC, but I need further
> > insight from a professionals like yourselves.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On July 16, 2018 7:51 AM, johnar1 johnar1 at protonmail.com wrote:
> > System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
> > I have successfully compiled mlt and ffmpeg with nvenc support
> > using the official nvenc headers stripped from the Nvidia SDK.
> > Rendering the first minute of the 1080p Sintel version, with 4
> > threads specified and my nvenc profile, finishes in 10 seconds.
> > Sintel can be downloaded here: https://durian.blender.org/download/
> > Nvenc Profile: (compatible with recent mlt versions who are
> > nvenc enabled by deafult)
> > f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
> > Now here is the problem that I do not understand:
> > Using the latest version of kdenlive from the kdenlive-master
> > ppa combined with the newly compiled versions of ffmpeg and mlt
> > works perfectly, but only under very specific circumstances.
> > I have only been able to get rendering with nvenc to work
> > properly when I use and open this specific kdenlive [b]save
> > file[/b] which I made of the first minute of the Sintel short
> > film with the Appimage Version of Kdenlive. After launching the
> > ppa/installed version of kdenlive and opening this save file,
> > rendering with nvenc works flawlessly.
> > If I simply start a new project, adding the whole Sintel short
> > film to the project bin, cutting the first minute and render it,
> > nvenc simply does not work and the render time is tripled,
> > despite having changed nothing else, including the nvenc render
> > profile.
> > If I create a save file of the first minute of Sintel with the
> > installed version and open it on the Appimage version, nvenc
> > does not work again.
> > Conclusion: There must be something in this save file, maybe a
> > parameter, additonal settings or any type of code not present in
> > the default kdenlive project profiles, which enables NVENC.
> > I would greatly appreciate it if we could find out the source
> > of this problem together.
> > Kdenlive Appimage Save File with which NVENC works:
> > https://pastebin.com/rzjR57DJ
> > PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
> > https://pastebin.com/3uQ8sP0C



From johnar1 at protonmail.com  Sat Jul 28 16:05:09 2018
From: johnar1 at protonmail.com (johnar1)
Date: Sat, 28 Jul 2018 11:05:09 -0400
Subject: Incredible Render Performance In Kdenlive With NVENC - But 1 Big
 Problem
In-Reply-To: <q5vCE89ZxIwHGGxd1af7No-H-L3TUFZY_cW73VBCYOKHScqRjzlrkkUkejYtrvY-6AiilhE81wLoKTDwqA8TB_PBwufMGGVSB9yZLN_qCpE=@protonmail.com>
References: <PztRbw9wffRaVK9AITI8vkXCNz1zSviVyeg2YshCBtcLqMWPdiE2x001c0W5dz20Qk40sQjOgnjAfRod0e9AjT1n3U4c468nPz-si6wt-sg=@protonmail.com>
 <RCXhUFq_4SQqR0mhZDH2bz2RjOkIU3ZIAt4BXyeSGFqJHxY40kdwfXwuh-YIR8GDdGGkgsnxZ3IRI6fMw0PZsNT05uo4dsGJZCI95Z9WEVk=@protonmail.com>
 <5784499.zTCVWVEayy@pad>
 <w5wNBhDVw3Ty_WGPoXVNUXG9iH9SYAi5REtB-G--lMyuEtJcsIV5yHPzeZUnQdnCqLZEGhlY5beBVdH7pO6WV9yxkIdOiVb-BXyBuIy1R4g=@protonmail.com>
 <db8abb46-8ec3-9b1d-317d-dd0a430ae701@kdenlive.org>
 <kh1MyUwt3vqLZKClvzue_xwmmPaM_GQ7SMLBrVUI9FOwVMXimxL9iHTNpfcqofsd0GoMG6bggcImQLfkhn41EI7TGUtUq5rPUzC7vKJvXS8=@protonmail.com>
 <0e9086e8-1a5a-7c1c-e917-7885d298e398@kdenlive.org>
 <cgzwWIYNQZQEmvspbtuqW_YfwFamWYn2sPAQMQhAlFkTD2QTqecsWcmiKepnioHSwxbLjV-jtpJNUO5wSgQtKqDiJ57OMBfCCM8ee42dhI0=@protonmail.com>
 <11185f96-e3fc-455e-9f96-436f8dc78a43@kdenlive.org>
 <q5vCE89ZxIwHGGxd1af7No-H-L3TUFZY_cW73VBCYOKHScqRjzlrkkUkejYtrvY-6AiilhE81wLoKTDwqA8TB_PBwufMGGVSB9yZLN_qCpE=@protonmail.com>
Message-ID: <6HIxNa7Uil0urihYwJRGQwsdlZ0cjOUkmOx96VN1dzG-7egqewGEXXvq4vg4MBsWbOt6kW9xBVfJBT8Fbmq42hH4L6IBWNgziF_z0sbSSpY=@protonmail.com>


*
Let's render the 1st minute of the h.264 version and post the results.

I am using melt 6.11, 6600K 4.5GHZ, 1050TI no OC, kdenlive 18.08 refractoring, my nvenc profile that I sent you a couple days ago (use that too if you can), nvidia-390, Lubuntu 18.04 with 4.15 Kernel and residual kdenlive environment binaries from Dan Dennedy's melt-build.sh.

Regards!

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 28, 2018 5:02 PM, johnar1 <johnar1 at protonmail.com> wrote:

> Hey Jean!
>
> So you are saying, that the reason why there is very low CPU usage and no NVENC usage with the Sintel clip, is because it's not exactly 1920x1080p resolution?
> I shall test different clips then.
>
> What version of kdenlive are you using?
> Also what versions of ffmpeg, ffprobe, ffplay, and melt?
>
> Some info on your CPU, general hardware setup and platform would be nice too.
>
> I would like to link up with you and run tests on the same footage.
>
> I have a 1050TI lying around here and a 6600K, let's compare our results in a similar testing environment.
>
> Just reinstalled Lubuntu 18.04 and working on the kdenlive 18.08 refractoring release.
>
> Let's use this as a sample: https://peach.blender.org/download/
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On July 27, 2018 2:29 PM, Jean-Baptiste Mardelle jb at kdenlive.org wrote:
>
> > On Thursday, July 26, 2018 6:17:52 PM CEST, johnar1 wrote:
> >
> > > I use 16.04 and 18.04 and I have found that using any kernel
> > >
> > > > 4.15 severly breaks the nvidia-driver.
> > >
> > > I am currently compiling 4.18 rc3 with the fixed modules to
> > > bypass the error caused with the driver but it's a pain.
> > > NVENC is a nice feature, but if you use a lot of transitions,
> > > effects and title clips in kdenlive, then it's almost pointless,
> > > because gpu utilization is basically halted during these
> > > operations.
> > > Tell me if you got it working.
> > > And definitely try the Shotcut melt binary, it has given me
> > > even better nvenc performance than my self-compiled melt 6.11
> > > from the latest git.
> >
> > Hello!
> > So I got nvenc working and have some interesting results. First, regarding
> > the slowdown with the high quality track compositing:
> > The transition used for tracks high quality compositing (qtblend) has some
> > code to detect if a compositing is necessary. For example, if the video on
> > the top track uses a pixel format that does not use alpha, like RGB, we
> > don't try to perform the composition, and directly return the top frame as
> > a result. There are several checks to make sure we don't need to do the
> > compositing, and one of them is a check of the aspect ratio. If the frames
> > aspect ratio don't match, we do perform the compositing. Useful for example
> > if you put a small image on a track above a video track, you usually want
> > to be able to see the video in the area not covered by the image.
> > This is the reason for the slowdown on rendering with high quality, because
> > your sample sintel movie is in fact a 1920x818 video, with a DAR (display
> > aspect ratio) of 960:409.
> > So it does not match the 1920x1080, 16:9 DAR project property, and so we do
> > perform the compositing, slowing down the process. Not sure what is the
> > best way to handle this, but we can probably find a solution to prevent
> > compositing in some cases.
> > Now regarding the nvenc performance, I also got some very encouraging
> > results. Using a 1920x1080 mp4 sample clip of 46 seconds, I got the
> > following results with my GTX 1050 TI card (all tests use the default "high
> > quality" track compositing):
> > Test 1: No effects, one clip in timeline. Render times:
> > libxvid: 1m30s
> > nvenc: 7s (!!!)
> > Test 2: one clip in timeline, with lift/gamma/gain color correction. Render
> > times:
> > libxvid: 1m29s
> > nvenc: 36s
> > Test 3: one clip in timeline, with sepia effect. Render times:
> > libxvid: 1m29s
> > nvenc: 8s
> > (sepia filter works in yuv422, while lift/gamma/gain requires an rgb
> > colorspace, which explains the performance diff).
> > Test 4: 1 exta image clip composited over the video. Render times:
> > libxvid: 1m37s
> > nvenc: 1m02s
> > So even with effects and transitions we still get a comfortable time gain.
> > It will also be interesting to integrate this in Kdenlive's internal uses,
> > like timeline preview and creating proxy clips which will make everything
> > faster (I successfully created I frame only clips with nvenc so we can get
> > a frame accurate seeking). I also made some tests with the scale_npp
> > rescale filter:
> > ffmpeg -y -hwaccel cuvid -c:v h264_cuvid -i Sintel.2010.1080p.mkv -filter:v
> > scale_npp=320:200 -vcodec h264_nvenc result.mp4
> > transcoding (using ffmpeg only) the full movie to 320x200 proxy:
> > using nvenc and scale_npp: 43s.
> > Using nvenc the normal ffmpeg's scale filter: 1m18s
> > Using libxvid and normal scale filter: 1m31s
> > Compared to no resize:
> > using nvenc without resizing: 1m11s
> > using libxvid without resizing: 6m08s
> > So that means we can should be able to create proxy clips twice as fast,
> > and timeline preview probably also.
> > The only sad part is that it requires the NVIDIA proprietary drivers, but
> > maybe FFmpeg's other free hwaccel methods will be usable as well in the
> > future. If anybody wants to test other hardware, you are welcome.
> > I will anyways integrate these nvenc speedups in the big december 2018
> > refactoring release.
> > Best regards
> > Jean-Baptiste
> >
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On July 26, 2018 10:47 AM, jb jb at kdenlive.org wrote:
> > > Le 26.07.18 à 10:02, johnar1 a écrit :
> > > Hello Jean,
> > > yes that is correct, switching from High Quality compositing
> > > had a major impact on performance and I am not sure why.
> > > I can help you out getting NVENC to work.
> > > What platform are you on?
> > > Thanks. My main issue is the NVidia driver, since I currently
> > > use an Ubuntu 16.04 based distro, and FFmpeg complains about my
> > > NVIDIA driver version < 390. I will upgrade my distro and give
> > > some feedback tomorrow.
> > > After that I guess a page on setting up nvenc would be nice on our wiki:
> > > https://community.kde.org/Kdenlive/Development/KF5
> > > Regards
> > > Jean-Baptiste
> > > There are a couple things to be mindful of.
> > > .)After installing the graphics driver you need to genereate an xorg.conf
> > > .)Install the NVENC Headers from here:
> > > https://github.com/lutris/ffmpeg-nvenc/issues/22
> > > .)Use the correct NVENC parameter in your render profile, as
> > > the current one has been deprecated.
> > > Here's my profile:
> > > f=mp4 vcodec=h264_nvenc gb=21 vq=21 acodec=aac ab=384k r=60
> > > preset= slow g=120 bf=2
> > > .)You need to compile ffmpeg and mlt with the following flags:
> > > ./configure --enable-nvenc --enable-cuvid --enable-nonfree
> > > Or if you don't want to compile yourself you can simply use the
> > > melt binary + libs from the most recent Shotcut build.
> > > https://github.com/mltframework/shotcut/releases/download/v18.07/shotcut-linux-x86_64-180702.tar.bz2
> > > Instructions here:
> > > https://www.youtube.com/watch?v=X14GvmBpq08&t=314s
> > > This will get NVENC working 100%.
> > > When you're done, you need to track the GPU utilization in the
> > > driver and make sure it is working. How many frames your GPU can
> > > push depends on the power of your CPU. I use the
> > > kdenlive_multirender script to ensure 100% utilization on all
> > > cores and subsequently higher GPU utilization.
> > > https://github.com/unfa/kdenlive-multirender
> > > Let's keep in touch!
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On July 26, 2018 9:30 AM, Jean-Baptiste Mardelle jb at kdenlive.org wrote:
> > > On 25.07.2018 21:38, johnar1 wrote:
> > > Dear Mr. Vincent Pinon,
> > > if that is in fact your real name, my first born son shall
> > > henceforth be known as Vincent.
> > > Your suggestion was spot on and according to my tests so far I
> > > believe it works.
> > > Here are my findings:
> > > Rendering 1st minute of Sintel 1080p/60FPS , 4 Threads, NVENC
> > > enabled, Kdenlive 18.04 AppImage
> > > Hello Johnar,
> > > I am myself trying to setup a working nvenc environment and
> > > hope to make some more tests.
> > > .)Track Composition - "None"
> > > [CPU Utilization: 70% - 67% - 64% - 80%] [GPU Utilization: 70%]
> > > [Render Time: 15s]
> > > I noticed however, that transitions such as for example Slide
> > > or Composite are rendered improperly, with certain interference
> > > patterns.
> > > After consulting the documentation, I realized that this should
> > > be fixed by disabling any surrounding empty tracks, but so far I
> > > have not been able to achieve that.
> > > .)Track Composition - "Preview"
> > > [CPU Utilization: 67% - 65% - 69% - 75%] [GPU Utilization: 65%]
> > > [Render Time: 20s]
> > > I conclude that the best of both worlds comes into play with
> > > this option enabled.
> > > Both the GPU and CPU are almost fully utilized, while it
> > > appears that transitions are rendered correctly.
> > > So if I understand correctly, rendering the same project with
> > > Track compositing set to "High Quality" has a major impact and
> > > you get this result:
> > > [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine
> > > Utilization (NVENC): 8%] [Render Time: 2m54s]
> > > This seems strange to me since Kdenlive's "high quality" track
> > > compositing uses the qtblend transition that should
> > > automatically be bypassed when there is no transparency in the
> > > video. If you can confirm that and that this simple change in
> > > track compositing has such an impact this definitely has to be
> > > checked... Also, Dan recently fixed many of the "affine"
> > > transition issue, so it should give results similar to the
> > > "qtblend" transition but may be faster..
> > > Thanks for all your investigations, I hope to come back with
> > > more infos once I successfully achieve my setup.
> > > Best regards
> > > Jean-Baptiste
> > > I will do more thorough testing and read any documentation
> > > available, as I absolutely want to understand what exactly these
> > > options do.
> > > I think it's a bit counterintutive to have "High Quality"
> > > enabled by default, which so heavily impacts performance, while
> > > in my opinion not making enough of an effort to alert the user
> > > to the extreme effects it may have on render times.
> > > I literally spent 72 hours straight, compiling every single
> > > version of melt and kdenlive, documenting and testing every
> > > possible compilation parameter variation, performance reviews
> > > with every available version of Ubuntu, corresponding kernels
> > > and nvidia drivers, and every remotely related kdenlive option
> > > or workarounds.
> > > This has definitely shortened my life span by about 3 - 4 years.
> > > I would like to extend my gratitude to you, good sir.
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On July 25, 2018 2:23 AM, Vincent Pinon vpinon at kde.org wrote:
> > > Hello,
> > > I don't know how precisely you do the job in kdenlive
> > > (you could share the .kdenlive, the .sh.mlt, a screenshot),
> > > one thing I suspect is the track composition (automatic transparency):
> > > if you keep the default high quality choice,
> > > kdenlive adds "composite & transform" transitions that are based on Qt.
> > > So without gpl / qt module, MLT skips these transitions.
> > > Could you run your test switching to "no transparency"?
> > > (toolbar just above timeline)
> > > Thanks for you enthusiastic investigations :)
> > > Vincent
> > > Le mardi 24 juillet 2018, 23:26:01 CEST johnar1 a écrit :
> > > Hey guys, I have some more info.
> > > Hey Eugen, I have some more info.
> > > For this test I used mlt 6.11, successfully compiled by Dan
> > > Dennedy's build-melt.sh
> > > The test file that I am using is the 1080p version of Sintel.
> > > https://durian.blender.org/download/
> > > CPU: i5 6600K, GPU:GTX 750 TI nvidia-390 driver , Platform: Kubuntu 18.04
> > > In order to check melt and isolate the problem I simply
> > > rendered the first minute of the Sintel short film with the
> > > following command:
> > > (This is not the /bin/melt, but the script which launches it
> > > with the correct libs)
> > > /home/frank/melt/20180724/melt -profile atsc_1080p_60
> > > sintel.mkv out=3600 -consumer avformat:result-60.mp4 f=mp4
> > > vcodec=h264_nvenc preset=slow
> > > [CPU Utilization: 67% - 70% - 68% - 74%] [Video Engine
> > > Utilization (NVENC): 80%] [Render Time: 20s]
> > > It obviously works perfectly.
> > > Now when I select this melt in the kdenlive environment, and
> > > also ffmpeg, ffplay, ffprobe and the profiles path from Dan's
> > > melt folder, yields the following results when rendering the
> > > first minute of Sintel.
> > > [CPU Utilization: 100% - 7% - 10% - 18%] [Video Engine
> > > Utilization (NVENC): 8%] [Render Time: 2m54s]
> > > Something in kdenlive breaks parallel processing, only allowing
> > > 1 single core to be fully utilized.
> > > And I have tested every single version of kdenlive available on this earth.
> > > Every app image, including the refractoring version and every
> > > single ppa version, including stable, dev and master.
> > > Also generating and launching the render script from the
> > > terminal yields the same result.
> > > RENDERER="/home/frank/kdenlive/bin/kdenlive_render"
> > > MELT="/home/frank/melt/20180724/melt"
> > > SOURCE_0="file:///home/frank/Documents/scripts/script001.sh.mlt"
> > > TARGET_0="file:///home/frank/Documents/untitled.mkv"
> > > PARAMETERS_0="-pid:2664 in=0 out=3052 $MELT atsc_1080p_60
> > > avformat - $SOURCE_0 $TARGET_0 vcodec=nvenc_h264 threads=4
> > > real_time=-1"
> > > $RENDERER $PARAMETERS_0
> > > I have also tested different kdenlive_render executables/libs
> > > with the same result.
> > > I should note, that using the kdenlive_multirender script in
> > > conjunction with the generated render script by kdenlive, while
> > > specifying 4 threads, the CPU uses 2 cores at 100%.
> > > https://github.com/unfa/kdenlive-multirender
> > > Now as I have described before, when I compile melt without
> > > enabling gpl, the 1 minute of Sintel renders perfectly again,
> > > with full utilization on both the CPU and GPU, but from within
> > > Kdenlive this time.
> > > I conclude that this problem is somehow caused by Kdenlive and
> > > related to qt, but I do not possess the knowhow to further
> > > analyze it.
> > > With the latest 18.08 Beta18 and the most recent QT version, 2
> > > cores instead of 1 are now being utilized at 100% with the NVENC
> > > profile and 100% on all 4 cores using the MP4 h264 profile.
> > > So this is 100% a QT issue with NVENC, but I need further
> > > insight from a professionals like yourselves.
> > > Sent with ProtonMail Secure Email.
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On July 16, 2018 7:51 AM, johnar1 johnar1 at protonmail.com wrote:
> > > System: i5 6600K, 1050TI, Ubuntu 18.04, Kernel 4.16
> > > I have successfully compiled mlt and ffmpeg with nvenc support
> > > using the official nvenc headers stripped from the Nvidia SDK.
> > > Rendering the first minute of the 1080p Sintel version, with 4
> > > threads specified and my nvenc profile, finishes in 10 seconds.
> > > Sintel can be downloaded here: https://durian.blender.org/download/
> > > Nvenc Profile: (compatible with recent mlt versions who are
> > > nvenc enabled by deafult)
> > > f=mp4 vcodec=nvenc_h264 global_quality=21 vq=21 preset=slow bf=2 ab=384k
> > > Now here is the problem that I do not understand:
> > > Using the latest version of kdenlive from the kdenlive-master
> > > ppa combined with the newly compiled versions of ffmpeg and mlt
> > > works perfectly, but only under very specific circumstances.
> > > I have only been able to get rendering with nvenc to work
> > > properly when I use and open this specific kdenlive [b]save
> > > file[/b] which I made of the first minute of the Sintel short
> > > film with the Appimage Version of Kdenlive. After launching the
> > > ppa/installed version of kdenlive and opening this save file,
> > > rendering with nvenc works flawlessly.
> > > If I simply start a new project, adding the whole Sintel short
> > > film to the project bin, cutting the first minute and render it,
> > > nvenc simply does not work and the render time is tripled,
> > > despite having changed nothing else, including the nvenc render
> > > profile.
> > > If I create a save file of the first minute of Sintel with the
> > > installed version and open it on the Appimage version, nvenc
> > > does not work again.
> > > Conclusion: There must be something in this save file, maybe a
> > > parameter, additonal settings or any type of code not present in
> > > the default kdenlive project profiles, which enables NVENC.
> > > I would greatly appreciate it if we could find out the source
> > > of this problem together.
> > > Kdenlive Appimage Save File with which NVENC works:
> > > https://pastebin.com/rzjR57DJ
> > > PPA/Installed Version of Kdenlive created Save File which breaks NVENC:
> > > https://pastebin.com/3uQ8sP0C



From andres.tello at gmail.com  Fri Jul 27 18:07:02 2018
From: andres.tello at gmail.com (andres tello)
Date: Fri, 27 Jul 2018 12:07:02 -0500
Subject: rotate a video
In-Reply-To: <3b009bce-ed50-666e-f679-65895ac6d0b2@dodin.org>
References: <9ded8889-c832-585f-8eb6-efe8301029c2@dodin.org>
 <CAArVfJdwUbvJoO0PFRXpUCGeKJZCMNSM6YPLREO+dGCjd1d4aw@mail.gmail.com>
 <3b009bce-ed50-666e-f679-65895ac6d0b2@dodin.org>
Message-ID: <CAArVfJdmLt5_e7=mQQAbAPALiceFd6aYTCASZoQQjyhqMvvEgA@mail.gmail.com>

zomming at kdelive is really easy
[image: image.png]

[image: image.png]

[image: image.png]

And that's it...
Misc Zoompan I never use it, I use Crop and Transform Position and Zoom...
you can have a zoom in or zoom out in 1% granularity...barely noticable,
just to cover your dark corners...


On Fri, Jul 27, 2018 at 11:45 AM jdd at dodin.org <jdd at dodin.org> wrote:

> Le 27/07/2018 à 18:27, andres tello a écrit :
> > the background is solid?
>
> the video is full screen, no (normally no) background :-(
>
> on most of the clips the borders are very dark, so I didn't notice the
> problem at first :-(
>
> >   And lastly, I would do a litle % of zoom, but you said you can't do
> it...
> >
>
> I don't find easy, in kdenlive, to zoom out, a good idea could be to add
> a second resizing frame inside the image :-)
>
> thanks
> jdd
>
>
> --
> http://dodin.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180727/41f7916b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 267173 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180727/41f7916b/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 291545 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180727/41f7916b/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 506241 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20180727/41f7916b/attachment-0005.png>