From harald.albrecht at gmx.net Tue Aug 1 06:20:52 2017 From: harald.albrecht at gmx.net (Harald Albrecht) Date: Tue, 01 Aug 2017 08:20:52 +0200 Subject: AW: timeline corruptions Message-ID: As for #3, my experience with stable/master is that you should click, drag, wait but don't release, then drag further, wait, drag, ..., release. Often, the intermittent stops without releasing the mouse button are where the corruption creeps in. Best regards, Harald -------- Ursprüngliche Nachricht -------- Von: farid abdelnour Datum: 01.08.17 01:13 (GMT+01:00) An: kdenlive Betreff: timeline corruptions hey guys, some tests we can do to see if the timeline corruptions happen when testing the refactoring branch are these: 1- speed effect 2- undo/redo various times after moving clips and restart project 3- move many clips at the same time through the timeline do you know/suspect of any other? write them here so we can thoroughly test this. jb and alcinos, is this something helpful to do? cheers -- 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| gunga tempoecoarteatelier-labsrede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From evorster at gmail.com Tue Aug 1 06:36:55 2017 From: evorster at gmail.com (Evert Vorster) Date: Tue, 1 Aug 2017 07:36:55 +0100 Subject: timeline corruptions In-Reply-To: References: Message-ID: Hi there... The timeline refactoring was widely touted as a fix for many bugs, and I have been waiting patiently for the refactoring to be comleted. It would only make sense to try and recreate the bugs already open against kdenlive in the timeline-refactored version. One immediate benefit would be that the list of open bugs against Kdenlive shrinks, and we identify where the real problems remain. Kind regards, Evert Vorster On 1 August 2017 at 07:20, Harald Albrecht wrote: > As for #3, my experience with stable/master is that you should click, > drag, wait but don't release, then drag further, wait, drag, ..., release. > Often, the intermittent stops without releasing the mouse button are where > the corruption creeps in. > > Best regards, > Harald > > > > -------- Ursprüngliche Nachricht -------- > Von: farid abdelnour > Datum: 01.08.17 01:13 (GMT+01:00) > An: kdenlive > Betreff: timeline corruptions > > hey guys, > > some tests we can do to see if the timeline corruptions happen when > testing the refactoring branch are these: > > 1- speed effect > 2- undo/redo various times after moving clips and restart project > 3- move many clips at the same time through the timeline > > do you know/suspect of any other? write them here so we can thoroughly > test this. > > jb and alcinos, is this something helpful to do? > > cheers > > -- > 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| > gunga > tempoecoarte > atelier-labs > rede mocambos > -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb at kdenlive.org Thu Aug 3 06:31:37 2017 From: jb at kdenlive.org (Jean-Baptiste Mardelle) Date: Thu, 3 Aug 2017 08:31:37 +0200 Subject: timeline corruptions In-Reply-To: References: Message-ID: On 01.08.2017 08:36, Evert Vorster wrote: > Hi there... Hi all, > The timeline refactoring was widely touted as a fix for many bugs, and I > have been waiting patiently for the refactoring to be comleted. Thanks for the patience :) We are also very excited to have a usable preview release soon. Scarlett is still working on the AppImage CI that should hopefully be ready by the end of august (maybe for next cafe) - otherwise we will look for other solutions to provide testing, because currently there is no other way to try it than compile it manually. > It would only make sense to try and recreate the bugs already open against > kdenlive in the timeline-refactored version. > One immediate benefit would be that the list of open bugs against Kdenlive > shrinks, and we identify where the real problems remain. I will try to update the Phabricator status page regarding our refactoring progress, but currently the basic timeline operations (move, delete, group/ungroup) and tools work (razor, spacer), as does undo. Effects / compositions are almost finished and mostly working (effect group not yet fully exposed). Clip markers, guides and proxy clips are also working. What remains to be done is: * effect compare * timeline preview * speed effect (this requires some special tricks in timeline) Then we can start work on advanced trimming, and other exciting stuff. So whenever we can provide a reliable way to test, the first steps would be as you suggested to test the timeline stability with move/cut/group/undo operations. Best regards and see you soon in next café (21st of august)! Jean-Baptiste > Kind regards, > Evert Vorster > > On 1 August 2017 at 07:20, Harald Albrecht wrote: > >> As for #3, my experience with stable/master is that you should click, >> drag, wait but don't release, then drag further, wait, drag, ..., release. >> Often, the intermittent stops without releasing the mouse button are where >> the corruption creeps in. >> >> Best regards, >> Harald >> >> >> >> -------- Ursprüngliche Nachricht -------- >> Von: farid abdelnour >> Datum: 01.08.17 01:13 (GMT+01:00) >> An: kdenlive >> Betreff: timeline corruptions >> >> hey guys, >> >> some tests we can do to see if the timeline corruptions happen when >> testing the refactoring branch are these: >> >> 1- speed effect >> 2- undo/redo various times after moving clips and restart project >> 3- move many clips at the same time through the timeline >> >> do you know/suspect of any other? write them here so we can thoroughly >> test this. >> >> jb and alcinos, is this something helpful to do? >> >> cheers >> >> -- >> 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| >> gunga >> tempoecoarte >> atelier-labs >> rede mocambos >> > From evorster at gmail.com Thu Aug 3 10:00:48 2017 From: evorster at gmail.com (Evert Vorster) Date: Thu, 3 Aug 2017 11:00:48 +0100 Subject: timeline corruptions In-Reply-To: References: Message-ID: Hi therem JBM. I can make a Arch Linux package for the refactoring branch, now that it is nearly usable. The only drawback with making these packages is that they replace the system package, so I have to wait until the branch is mostly usable. kdenlive-testing-git would be the name of the package. Kind regards, Evert Vorster On 3 August 2017 at 07:31, Jean-Baptiste Mardelle wrote: > On 01.08.2017 08:36, Evert Vorster wrote: > >> Hi there... >> > > Hi all, > >> The timeline refactoring was widely touted as a fix for many bugs, and I >> have been waiting patiently for the refactoring to be comleted. >> > Thanks for the patience :) We are also very excited to have a usable > preview release soon. Scarlett is still working on the AppImage CI that > should hopefully be ready by the end of august (maybe for next cafe) - > otherwise we will look for other solutions to provide testing, because > currently there is no other way to try it than compile it manually. > >> It would only make sense to try and recreate the bugs already open against >> kdenlive in the timeline-refactored version. >> One immediate benefit would be that the list of open bugs against Kdenlive >> shrinks, and we identify where the real problems remain. >> > > I will try to update the Phabricator status page regarding our refactoring > progress, but currently the basic timeline operations (move, delete, > group/ungroup) and tools work (razor, spacer), as does undo. > Effects / compositions are almost finished and mostly working (effect > group not yet fully exposed). Clip markers, guides and proxy clips are also > working. > > What remains to be done is: > * effect compare > * timeline preview > * speed effect (this requires some special tricks in timeline) > > Then we can start work on advanced trimming, and other exciting stuff. > > So whenever we can provide a reliable way to test, the first steps would > be as you suggested to test the timeline stability with move/cut/group/undo > operations. > > Best regards and see you soon in next café (21st of august)! > > Jean-Baptiste > > > > Kind regards, >> Evert Vorster >> >> On 1 August 2017 at 07:20, Harald Albrecht >> wrote: >> >> As for #3, my experience with stable/master is that you should click, >>> drag, wait but don't release, then drag further, wait, drag, ..., >>> release. >>> Often, the intermittent stops without releasing the mouse button are >>> where >>> the corruption creeps in. >>> >>> Best regards, >>> Harald >>> >>> >>> >>> -------- Ursprüngliche Nachricht -------- >>> Von: farid abdelnour >>> Datum: 01.08.17 01:13 (GMT+01:00) >>> An: kdenlive >>> Betreff: timeline corruptions >>> >>> hey guys, >>> >>> some tests we can do to see if the timeline corruptions happen when >>> testing the refactoring branch are these: >>> >>> 1- speed effect >>> 2- undo/redo various times after moving clips and restart project >>> 3- move many clips at the same time through the timeline >>> >>> do you know/suspect of any other? write them here so we can thoroughly >>> test this. >>> >>> jb and alcinos, is this something helpful to do? >>> >>> cheers >>> >>> -- >>> 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| >>> gunga >>> tempoecoarte >>> atelier-labs >>> rede mocambos >>> >>> >> > -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From evorster at gmail.com Thu Aug 3 10:16:51 2017 From: evorster at gmail.com (Evert Vorster) Date: Thu, 3 Aug 2017 11:16:51 +0100 Subject: timeline corruptions In-Reply-To: References: Message-ID: Hi there, JBM. I am in the process of making the kdenlive-testing-git package for Arch Linux. It will be tracking the refactoring_timeline branch for now, as that seems to be the branch with the most action. It's a pain to rename/remove packages in Arch Linux, so I do not want to make a package for each branch. Currently I am maintaining: kdenlive-git, tracking master kdenlive-release-git, tracking the latest release and now kdenlive-testing-git, which will track whichever branch you would like a wider audience to test. Please confirm that refactoring_timeline is the branch that you would like to have testing performed on. Kind regards, Evert On 3 August 2017 at 11:00, Evert Vorster wrote: > Hi therem JBM. > > I can make a Arch Linux package for the refactoring branch, now that it is > nearly usable. > The only drawback with making these packages is that they replace the > system package, so I have to wait until the branch is mostly usable. > > kdenlive-testing-git would be the name of the package. > > Kind regards, > Evert Vorster > > On 3 August 2017 at 07:31, Jean-Baptiste Mardelle wrote: > >> On 01.08.2017 08:36, Evert Vorster wrote: >> >>> Hi there... >>> >> >> Hi all, >> >>> The timeline refactoring was widely touted as a fix for many bugs, and I >>> have been waiting patiently for the refactoring to be comleted. >>> >> Thanks for the patience :) We are also very excited to have a usable >> preview release soon. Scarlett is still working on the AppImage CI that >> should hopefully be ready by the end of august (maybe for next cafe) - >> otherwise we will look for other solutions to provide testing, because >> currently there is no other way to try it than compile it manually. >> >>> It would only make sense to try and recreate the bugs already open >>> against >>> kdenlive in the timeline-refactored version. >>> One immediate benefit would be that the list of open bugs against >>> Kdenlive >>> shrinks, and we identify where the real problems remain. >>> >> >> I will try to update the Phabricator status page regarding our >> refactoring progress, but currently the basic timeline operations (move, >> delete, group/ungroup) and tools work (razor, spacer), as does undo. >> Effects / compositions are almost finished and mostly working (effect >> group not yet fully exposed). Clip markers, guides and proxy clips are also >> working. >> >> What remains to be done is: >> * effect compare >> * timeline preview >> * speed effect (this requires some special tricks in timeline) >> >> Then we can start work on advanced trimming, and other exciting stuff. >> >> So whenever we can provide a reliable way to test, the first steps would >> be as you suggested to test the timeline stability with move/cut/group/undo >> operations. >> >> Best regards and see you soon in next café (21st of august)! >> >> Jean-Baptiste >> >> >> >> Kind regards, >>> Evert Vorster >>> >>> On 1 August 2017 at 07:20, Harald Albrecht >>> wrote: >>> >>> As for #3, my experience with stable/master is that you should click, >>>> drag, wait but don't release, then drag further, wait, drag, ..., >>>> release. >>>> Often, the intermittent stops without releasing the mouse button are >>>> where >>>> the corruption creeps in. >>>> >>>> Best regards, >>>> Harald >>>> >>>> >>>> >>>> -------- Ursprüngliche Nachricht -------- >>>> Von: farid abdelnour >>>> Datum: 01.08.17 01:13 (GMT+01:00) >>>> An: kdenlive >>>> Betreff: timeline corruptions >>>> >>>> hey guys, >>>> >>>> some tests we can do to see if the timeline corruptions happen when >>>> testing the refactoring branch are these: >>>> >>>> 1- speed effect >>>> 2- undo/redo various times after moving clips and restart project >>>> 3- move many clips at the same time through the timeline >>>> >>>> do you know/suspect of any other? write them here so we can thoroughly >>>> test this. >>>> >>>> jb and alcinos, is this something helpful to do? >>>> >>>> cheers >>>> >>>> -- >>>> 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| >>>> gunga >>>> tempoecoarte >>>> atelier-labs >>>> rede mocambos >>>> >>>> >>> >> > > > -- > Evert Vorster > Isometrix Acquistion Superchief > > -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesse.dubord at gmail.com Thu Aug 3 20:17:44 2017 From: jesse.dubord at gmail.com (Jesse DuBord) Date: Thu, 03 Aug 2017 13:17:44 -0700 Subject: Ubuntu LTS packages for Master branch ppa? Message-ID: <1613237.bRuaZypiyG@primus> Didn't there used to be Kdenlive packages in the master development branch ppa for Xenial, Ubuntu's most recent LTS release? From snd.noise at gmail.com Fri Aug 4 01:30:03 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Thu, 3 Aug 2017 22:30:03 -0300 Subject: simple bug for 17.08? In-Reply-To: References: Message-ID: thanks a lot jb :) i spotted this one: https://forum.kde.org/viewtopic.php?f=279&t=139821 i can reproduce it but can't submit it as a bug report. cheers 2017-07-27 3:56 GMT-03:00 Jean-Baptiste Mardelle : > On 27.07.2017 06:53, farid abdelnour wrote: > >> hi >> >> Hi Farid, > > dont know if it is still possible to include a fix for this bug. >> >> https://bugs.kde.org/show_bug.cgi?id=382451 >> >> thanks :) >> > > Fixed, thanks for pointing it out. > > Regards > jb > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Fri Aug 4 01:37:52 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Thu, 3 Aug 2017 22:37:52 -0300 Subject: timeline corruptions In-Reply-To: References: Message-ID: hi evert, 2017-08-03 7:16 GMT-03:00 Evert Vorster : > Hi there, JBM. > I am in the process of making the kdenlive-testing-git package for Arch > Linux. > It will be tracking the refactoring_timeline branch for now, as that seems > to be the branch with the most action. > this is the refactoring branch: https://cgit.kde.org/kdenlive.git/log/?h=refactoring_timeline > It's a pain to rename/remove packages in Arch Linux, so I do not want to > make a package for each branch. > > Currently I am maintaining: > kdenlive-git, tracking master > kdenlive-release-git, tracking the latest release > and now kdenlive-testing-git, which will track whichever branch you would > like a wider audience to test. > i am a heavy user of kdenlive-git from aur, thanks :D maybe you could install the refactoring branch in /opt and have the provides parameter in the pkgbuild use something like kdenlive-refactor, that way we'll be able to test it without removing the main version. > Please confirm that refactoring_timeline is the branch that you would like > to have testing performed on. > happy to test your package whenever it is ready. > > Kind regards, > Evert > also On 3 August 2017 at 11:00, Evert Vorster wrote: > >> Hi therem JBM. >> >> I can make a Arch Linux package for the refactoring branch, now that it >> is nearly usable. >> The only drawback with making these packages is that they replace the >> system package, so I have to wait until the branch is mostly usable. >> >> kdenlive-testing-git would be the name of the package. >> >> Kind regards, >> Evert Vorster >> >> On 3 August 2017 at 07:31, Jean-Baptiste Mardelle >> wrote: >> >>> On 01.08.2017 08:36, Evert Vorster wrote: >>> >>>> Hi there... >>>> >>> >>> Hi all, >>> >>>> The timeline refactoring was widely touted as a fix for many bugs, and I >>>> have been waiting patiently for the refactoring to be comleted. >>>> >>> Thanks for the patience :) We are also very excited to have a usable >>> preview release soon. Scarlett is still working on the AppImage CI that >>> should hopefully be ready by the end of august (maybe for next cafe) - >>> otherwise we will look for other solutions to provide testing, because >>> currently there is no other way to try it than compile it manually. >>> >>>> It would only make sense to try and recreate the bugs already open >>>> against >>>> kdenlive in the timeline-refactored version. >>>> One immediate benefit would be that the list of open bugs against >>>> Kdenlive >>>> shrinks, and we identify where the real problems remain. >>>> >>> that is the idea actually, those 3 i posted are on the tracker, if you know of other specific corruption issues post them here as well... we should eventually have a bug squash for this. cheers :D > >>> I will try to update the Phabricator status page regarding our >>> refactoring progress, but currently the basic timeline operations (move, >>> delete, group/ungroup) and tools work (razor, spacer), as does undo. >>> Effects / compositions are almost finished and mostly working (effect >>> group not yet fully exposed). Clip markers, guides and proxy clips are also >>> working. >>> >>> What remains to be done is: >>> * effect compare >>> * timeline preview >>> * speed effect (this requires some special tricks in timeline) >>> >>> Then we can start work on advanced trimming, and other exciting stuff. >>> >>> So whenever we can provide a reliable way to test, the first steps would >>> be as you suggested to test the timeline stability with move/cut/group/undo >>> operations. >>> >>> Best regards and see you soon in next café (21st of august)! >>> >>> Jean-Baptiste >>> >>> >>> >>> Kind regards, >>>> Evert Vorster >>>> >>>> On 1 August 2017 at 07:20, Harald Albrecht >>>> wrote: >>>> >>>> As for #3, my experience with stable/master is that you should click, >>>>> drag, wait but don't release, then drag further, wait, drag, ..., >>>>> release. >>>>> Often, the intermittent stops without releasing the mouse button are >>>>> where >>>>> the corruption creeps in. >>>>> >>>>> Best regards, >>>>> Harald >>>>> >>>>> >>>>> >>>>> -------- Ursprüngliche Nachricht -------- >>>>> Von: farid abdelnour >>>>> Datum: 01.08.17 01:13 (GMT+01:00) >>>>> An: kdenlive >>>>> Betreff: timeline corruptions >>>>> >>>>> hey guys, >>>>> >>>>> some tests we can do to see if the timeline corruptions happen when >>>>> testing the refactoring branch are these: >>>>> >>>>> 1- speed effect >>>>> 2- undo/redo various times after moving clips and restart project >>>>> 3- move many clips at the same time through the timeline >>>>> >>>>> do you know/suspect of any other? write them here so we can thoroughly >>>>> test this. >>>>> >>>>> jb and alcinos, is this something helpful to do? >>>>> >>>>> cheers >>>>> >>>>> -- >>>>> 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| >>>>> gunga >>>>> tempoecoarte >>>>> atelier-labs >>>>> rede mocambos >>>>> >>>>> >>>> >>> >> >> >> -- >> Evert Vorster >> Isometrix Acquistion Superchief >> >> > > > -- > Evert Vorster > Isometrix Acquistion Superchief > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb at kdenlive.org Fri Aug 4 05:41:05 2017 From: jb at kdenlive.org (Jean-Baptiste Mardelle) Date: Fri, 4 Aug 2017 07:41:05 +0200 Subject: simple bug for 17.08? In-Reply-To: References: Message-ID: <197f919b-b3ec-8808-447d-fdadabb096d0@kdenlive.org> On 04.08.2017 03:30, farid abdelnour wrote: > thanks a lot jb :) > > i spotted this one: > https://forum.kde.org/viewtopic.php?f=279&t=139821 > > i can reproduce it but can't submit it as a bug report. > Fixed, nice catch. Regards jb > > 2017-07-27 3:56 GMT-03:00 Jean-Baptiste Mardelle : > >> On 27.07.2017 06:53, farid abdelnour wrote: >> >>> hi >>> >>> Hi Farid, >> dont know if it is still possible to include a fix for this bug. >>> https://bugs.kde.org/show_bug.cgi?id=382451 >>> >>> thanks :) >>> >> Fixed, thanks for pointing it out. >> >> Regards >> jb >> >> > From snd.noise at gmail.com Fri Aug 4 07:35:57 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Fri, 4 Aug 2017 04:35:57 -0300 Subject: simple bug for 17.08? In-Reply-To: <197f919b-b3ec-8808-447d-fdadabb096d0@kdenlive.org> References: <197f919b-b3ec-8808-447d-fdadabb096d0@kdenlive.org> Message-ID: thanks jb, :D 2017-08-04 2:41 GMT-03:00 Jean-Baptiste Mardelle : > On 04.08.2017 03:30, farid abdelnour wrote: > >> thanks a lot jb :) >> >> i spotted this one: >> https://forum.kde.org/viewtopic.php?f=279&t=139821 >> >> i can reproduce it but can't submit it as a bug report. >> >> > Fixed, nice catch. > > Regards > jb > > > >> 2017-07-27 3:56 GMT-03:00 Jean-Baptiste Mardelle : >> >> On 27.07.2017 06:53, farid abdelnour wrote: >>> >>> hi >>>> >>>> Hi Farid, >>>> >>> dont know if it is still possible to include a fix for this bug. >>> >>>> https://bugs.kde.org/show_bug.cgi?id=382451 >>>> >>>> thanks :) >>>> >>>> Fixed, thanks for pointing it out. >>> >>> Regards >>> jb >>> >>> >>> >> > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From uservth at krutt.org Sat Aug 5 21:42:57 2017 From: uservth at krutt.org (VTH) Date: Sat, 05 Aug 2017 21:42:57 +0000 Subject: Title Clip Window on i3wm Message-ID: Hello, i have a problem (and a suggestion). I use the 13 tilling windows manager, and as you should know, every window is widely open to fulfill the screen. Well, Kdenlive runs wonderfully in this environment, except for the Title Clip Editing Window. The window is too large and i can not access to the save boton, or close the windows without the shortcut mod+shift+Q, even with mod+shift+W, mod+shift+E, or mod+shift+S the title clip edit windows does not moves or change. I think an image is better than words. I know there are very few people who uses 13Wm, but i think wold be a good improvement. Also i attach my system specifications. Thank you. -V- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Captura de pantalla_2017-08-05_17-24-41.png Type: image/png Size: 61505 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Captura de pantalla_2017-08-05_17-28-26.png Type: image/png Size: 734306 bytes Desc: not available URL: From snd.noise at gmail.com Mon Aug 7 03:21:38 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Mon, 7 Aug 2017 00:21:38 -0300 Subject: [showcase] short edited with Kdenlive Message-ID: Here is a short edited using Kdenlive by community member Jesse. https://www.youtube.com/watch?v=_sSIRGZnFms Congrats! -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Tue Aug 8 03:01:29 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Tue, 8 Aug 2017 00:01:29 -0300 Subject: possible regression when moving clips Message-ID: hi i started a project with 17.04.3 then updated to 17.11.70 and noticed a regression when moving clips in the timeline be it with the box select and then drag or with the spacer tool. if i open a new project in 17.11.70 and add twice as many clips to the timeline, i am able to drag them smoothy without issues. can anyone help debug/confirm this please? 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From b-misc at gmx.ch Tue Aug 8 09:35:39 2017 From: b-misc at gmx.ch (B.M.) Date: Tue, 08 Aug 2017 11:35:39 +0200 Subject: Hardware acceleration / vaapi Message-ID: Dear all, After some years without I'm getting back to video editing... I already searched quite a lot but it's really hard to find "realiable" information, so I decided to ask here: - It seems that hw accel is not available in kdenlive - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg can use hardware acceleration for de- and encoding. So is mlt to "blame" for missing hw accel. in kdenlive? - There has been a patch (bug 378832) "use of vaapi in transcoding and rendering" which seems to tackle my question. But what did it really change - / what is it for? I didn't find more info on that and it's in kdenlive 17.04, while Debian is at 16.12. and before I compile myself I'd like to get more info. - Furthermore I found a thread on this list back in April "kdenlive and mlt nvenc enabled" covering the same topic but for nvidia instead of Intel graphics; unfortunately nobody reported back if it really works. For me it reads like the patch I mentioned above. So regarding the current state of hw accel in kdenlive I'm still uncertain. Thank you for your inputs. Kind regards Bernd -------------- next part -------------- An HTML attachment was scrubbed... URL: From evorster at gmail.com Tue Aug 8 11:47:31 2017 From: evorster at gmail.com (Evert Vorster) Date: Tue, 8 Aug 2017 12:47:31 +0100 Subject: Hardware acceleration / vaapi In-Reply-To: References: Message-ID: Hi there, Bernd. Kdenlive supports hardware encoding through custom encoding profiles. This is my profile for hardware hevc encoding with nvidia: properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac crf=%quality ab=%audiobitrate+'k' It would have been awesome if mlt and ffmpeg used the same format in command lines, but this is not the case. At least they are close. Unfortunately I only have intel cards, so I cannot test the intel vaapi acelleration for you. Kind regards, On 8 August 2017 at 10:35, B.M. wrote: > Dear all, > > After some years without I'm getting back to video editing... I already > searched quite a lot but it's really hard to find "realiable" information, > so I decided to ask here: > > - It seems that hw accel is not available in kdenlive > > - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg can > use hardware acceleration for de- and encoding. So is mlt to "blame" for > missing hw accel. in kdenlive? > > - There has been a patch (bug 378832) "use of vaapi in transcoding and > rendering" which seems to tackle my question. But what did it really change > - > / what is it for? I didn't find more info on that and it's in kdenlive > 17.04, while Debian is at 16.12. and before I compile myself I'd like to > get more info. > > - Furthermore I found a thread on this list back in April "kdenlive and > mlt nvenc enabled" covering the same topic but for nvidia instead of Intel > graphics; unfortunately nobody reported back if it really works. For me it > reads like the patch I mentioned above. > > So regarding the current state of hw accel in kdenlive I'm still uncertain. > > Thank you for your inputs. > > Kind regards > Bernd -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From vpinon at kde.org Tue Aug 8 12:31:13 2017 From: vpinon at kde.org (Vincent Pinon) Date: Tue, 08 Aug 2017 14:31:13 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: References: Message-ID: <2475993.diM1DYiyZM@pad> Hello, Note that you need to have FFmpeg built with vaapi or nvenc support, which is not the case of Debian package. I don't know what's needed for Intel, but for NVidia you have to download a SDK linked to closed-source driver, providing personal information: showstopper for me (and many packagers) :\ Please let us know of any progress on your side. Evert, did you try to share your custom profiles using "HotNewStuff" function in Kdenlive? ;) Vincent Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : Hi there, Bernd. Kdenlive supports hardware encoding through custom encoding profiles. This is my profile for hardware hevc encoding with nvidia: properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac crf=%quality ab=%audiobitrate+'k' It would have been awesome if mlt and ffmpeg used the same format in command lines, but this is not the case. At least they are close. Unfortunately I only have intel cards, so I cannot test the intel vaapi acelleration for you. Kind regards, On 8 August 2017 at 10:35, B.M. wrote: Dear all, After some years without I'm getting back to video editing... I already searched quite a lot but it's really hard to find "realiable" information, so I decided to ask here: - It seems that hw accel is not available in kdenlive - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg can use hardware acceleration for de- and encoding. So is mlt to "blame" for missing hw accel. in kdenlive? - There has been a patch (bug 378832) "use of vaapi in transcoding and rendering" which seems to tackle my question. But what did it really change -/ what is it for? I didn't find more info on that and it's in kdenlive 17.04, while Debian is at 16.12. and before I compile myself I'd like to get more info. - Furthermore I found a thread on this list back in April "kdenlive and mlt nvenc enabled" covering the same topic but for nvidia instead of Intel graphics; unfortunately nobody reported back if it really works. For me it reads like the patch I mentioned above. So regarding the current state of hw accel in kdenlive I'm still uncertain. Thank you for your inputs. Kind regardsBernd Evert VorsterIsometrix Acquistion Superchief -------- [1] mailto:b-misc at gmx.ch -------------- next part -------------- An HTML attachment was scrubbed... URL: From vpinon at kde.org Tue Aug 8 12:47:14 2017 From: vpinon at kde.org (Vincent Pinon) Date: Tue, 08 Aug 2017 14:47:14 +0200 Subject: PPA to test future 17.12 (timeline rewrite) Message-ID: <15023171.3DjirpVA1A@pad> Hello, I've finally finished the setup of a new PPA to test the future Kdenlive 17.12 version, containing a "kdenlive-test" package that can coexist with a normal "kdenlive" package (17.04 or 17.08)... ppa:kdenlive/kdenlive-17.12preview The build lives in /opt/kdenlive-test I forgot to install an icon to a standard path, so you have to create one or run the command: /opt/kdenlive-test/bin/kdenlive As usual, I publish quickly before testing seriously, so be prepared for deception :-p Don't hesitate to send me your remarks, and if you find it interesting, I let you share the info on your networks (reminding this is experimental software)... Vincent. From b-misc at gmx.ch Tue Aug 8 12:50:15 2017 From: b-misc at gmx.ch (B.M.) Date: Tue, 08 Aug 2017 14:50:15 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: <2475993.diM1DYiyZM@pad> References: <2475993.diM1DYiyZM@pad> Message-ID: Hi all, Well so I can expect hw accel for ENcoding to work. What's about DEcoding? Can that be enabled as well? Is it correct that direct raw copying (no de- and re-encoding) is not possible? Would be soooo nice (speedup & image quality) for all the clips which rest unchanged! I know that this is a missing feature on the mlt side; having a background in programming myself I know how ugly a workaround can be, but: did you dev's discuss that in the past? As I said, only for unchanged clips (I have 4K editing in mind...) Best, Bernd PS: I will see how to compile ffmpeg with hw accel enabled. Am 8. August 2017 14:31:13 MESZ schrieb Vincent Pinon : >Hello, > >Note that you need to have FFmpeg built with vaapi or nvenc support, >which is not the case of Debian package. >I don't know what's needed for Intel, but for NVidia you have to >download a SDK linked to closed-source driver, providing personal >information: showstopper for me (and many packagers) :\ > >Please let us know of any progress on your side. > >Evert, did you try to share your custom profiles using "HotNewStuff" >function in Kdenlive? ;) > >Vincent > >Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > >Hi there, Bernd. > > > >Kdenlive supports hardware encoding through custom encoding profiles. > > >This is my profile for hardware hevc encoding with nvidia: > > >properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac >crf=%quality ab=%audiobitrate+'k' > > >It would have been awesome if mlt and ffmpeg used the same format in >command lines, but this is not the case. At least they are close. > > >Unfortunately I only have intel cards, so I cannot test the intel vaapi >acelleration for you. > > >Kind regards, > > >On 8 August 2017 at 10:35, B.M. wrote: > > >Dear all, > >After some years without I'm getting back to video editing... I already >searched quite a lot but it's really hard to find "realiable" >information, so I decided to ask here: > >- It seems that hw accel is not available in kdenlive > >- As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg >can use hardware acceleration for de- and encoding. So is mlt to >"blame" for missing hw accel. in kdenlive? > >- There has been a patch (bug 378832) "use of vaapi in transcoding and >rendering" which seems to tackle my question. But what did it really >change -/ what is it for? I didn't find more info on that and it's in >kdenlive 17.04, while Debian is at 16.12. and before I compile myself >I'd like to get more info. > >- Furthermore I found a thread on this list back in April "kdenlive and >mlt nvenc enabled" covering the same topic but for nvidia instead of >Intel graphics; unfortunately nobody reported back if it really works. >For me it reads like the patch I mentioned above. > >So regarding the current state of hw accel in kdenlive I'm still >uncertain. > >Thank you for your inputs. > >Kind regardsBernd > > >Evert VorsterIsometrix Acquistion Superchief > > > > > > >-------- >[1] mailto:b-misc at gmx.ch -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.albrecht at gmx.net Tue Aug 8 13:04:54 2017 From: harald.albrecht at gmx.net (harald.albrecht) Date: Tue, 08 Aug 2017 15:04:54 +0200 Subject: AW: PPA to test future 17.12 (timeline rewrite) Message-ID: +100 -------- Ursprüngliche Nachricht -------- Von: Vincent Pinon Datum: 08.08.17 14:47 (GMT+01:00) An: kdenlive at kde.org Betreff: PPA to test future 17.12 (timeline rewrite) Hello, I've finally finished the setup of a new PPA to test the future Kdenlive 17.12 version, containing a "kdenlive-test" package that can coexist with a normal "kdenlive" package (17.04 or 17.08)... ppa:kdenlive/kdenlive-17.12preview The build lives in /opt/kdenlive-test I forgot to install an icon to a standard path, so you have to create one or run the command: /opt/kdenlive-test/bin/kdenlive As usual, I publish quickly before testing seriously, so be prepared for deception :-p Don't hesitate to send me your remarks, and if you find it interesting, I let you share the info on your networks (reminding this is experimental software)... Vincent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Tue Aug 8 15:03:30 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Tue, 8 Aug 2017 12:03:30 -0300 Subject: Hardware acceleration / vaapi In-Reply-To: <2475993.diM1DYiyZM@pad> References: <2475993.diM1DYiyZM@pad> Message-ID: 2017-08-08 9:31 GMT-03:00 Vincent Pinon : > > Evert, did you try to share your custom profiles using "HotNewStuff" > function in Kdenlive? ;) > +1 > > > Vincent > > > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > Hi there, Bernd. > > Kdenlive supports hardware encoding through custom encoding profiles. > > This is my profile for hardware hevc encoding with nvidia: > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > crf=%quality ab=%audiobitrate+'k' > > > It would have been awesome if mlt and ffmpeg used the same format in > command lines, but this is not the case. At least they are close. > > Unfortunately I only have intel cards, so I cannot test the intel vaapi > acelleration for you. > > > Kind regards, > > > On 8 August 2017 at 10:35, B.M. wrote: > > Dear all, > > After some years without I'm getting back to video editing... I already > searched quite a lot but it's really hard to find "realiable" information, > so I decided to ask here: > > - It seems that hw accel is not available in kdenlive > > - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg can > use hardware acceleration for de- and encoding. So is mlt to "blame" for > missing hw accel. in kdenlive? > > - There has been a patch (bug 378832) "use of vaapi in transcoding and > rendering" which seems to tackle my question. But what did it really change > - > / what is it for? I didn't find more info on that and it's in kdenlive > 17.04, while Debian is at 16.12. and before I compile myself I'd like to > get more info. > > - Furthermore I found a thread on this list back in April "kdenlive and > mlt nvenc enabled" covering the same topic but for nvidia instead of Intel > graphics; unfortunately nobody reported back if it really works. For me it > reads like the patch I mentioned above. > > So regarding the current state of hw accel in kdenlive I'm still uncertain. > > Thank you for your inputs. > > Kind regards > Bernd > > > > > -- > > Evert Vorster > Isometrix Acquistion Superchief > > > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesse.dubord at gmail.com Tue Aug 8 17:56:20 2017 From: jesse.dubord at gmail.com (Jesse DuBord) Date: Tue, 08 Aug 2017 10:56:20 -0700 Subject: PPA to test future 17.12 (timeline rewrite) In-Reply-To: References: Message-ID: <1502214980.3482.0@smtp.gmail.com> Awesome stuff, Vincent! Appreciate the time you've taken to set all of this up. One comment: I did a poll on the Ubuntu G+ community, asking users whether they use the LTS ubuntu releases or the non-LTS. So far, over 1,090 people have voted, and a STAGGERING 71% use LTS releases on their primary machines (https://plus.google.com/+JesseDuBordFilms/posts/3VkkxrzCzZV). I might encourage support for the latest LTS release for Kdenlive PPA's, in both the new timeline ppa and the master ppa (seems like LTS support is already in stable ppa). Having packages for those LTS versions would expand the use of them, drastically, based on my findings. On Tue, Aug 8, 2017 at 6:05 AM, kdenlive-request at kde.org wrote: > Send kdenlive mailing list submissions to > kdenlive at kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/kdenlive > or, via email, send a message with subject or body 'help' to > kdenlive-request at kde.org > > You can reach the person managing the list at > kdenlive-owner at kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of kdenlive digest..." > > > Today's Topics: > > 1. Re: Hardware acceleration / vaapi (Vincent Pinon) > 2. PPA to test future 17.12 (timeline rewrite) (Vincent Pinon) > 3. Re: Hardware acceleration / vaapi (B.M.) > 4. AW: PPA to test future 17.12 (timeline rewrite) > (harald.albrecht) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 08 Aug 2017 14:31:13 +0200 > From: Vincent Pinon > To: kdenlive at kde.org > Subject: Re: Hardware acceleration / vaapi > Message-ID: <2475993.diM1DYiyZM at pad> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > Note that you need to have FFmpeg built with vaapi or nvenc support, > which is not the case of Debian package. > I don't know what's needed for Intel, but for NVidia you have to > download a SDK linked to closed-source driver, providing personal > information: showstopper for me (and many packagers) :\ > > Please let us know of any progress on your side. > > Evert, did you try to share your custom profiles using "HotNewStuff" > function in Kdenlive? ;) > > Vincent > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > Hi there, Bernd. > > > > Kdenlive supports hardware encoding through custom encoding profiles. > > > This is my profile for hardware hevc encoding with nvidia: > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > crf=%quality ab=%audiobitrate+'k' > > > It would have been awesome if mlt and ffmpeg used the same format in > command lines, but this is not the case. At least they are close. > > > Unfortunately I only have intel cards, so I cannot test the intel > vaapi acelleration for you. > > > Kind regards, > > > On 8 August 2017 at 10:35, B.M. wrote: > > > Dear all, > > After some years without I'm getting back to video editing... I > already searched quite a lot but it's really hard to find "realiable" > information, so I decided to ask here: > > - It seems that hw accel is not available in kdenlive > > - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg > can use hardware acceleration for de- and encoding. So is mlt to > "blame" for missing hw accel. in kdenlive? > > - There has been a patch (bug 378832) "use of vaapi in transcoding > and rendering" which seems to tackle my question. But what did it > really change -/ what is it for? I didn't find more info on that and > it's in kdenlive 17.04, while Debian is at 16.12. and before I > compile myself I'd like to get more info. > > - Furthermore I found a thread on this list back in April "kdenlive > and mlt nvenc enabled" covering the same topic but for nvidia instead > of Intel graphics; unfortunately nobody reported back if it really > works. For me it reads like the patch I mentioned above. > > So regarding the current state of hw accel in kdenlive I'm still > uncertain. > > Thank you for your inputs. > > Kind regardsBernd > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > -------- > [1] mailto:b-misc at gmx.ch > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Tue, 08 Aug 2017 14:47:14 +0200 > From: Vincent Pinon > To: kdenlive at kde.org > Subject: PPA to test future 17.12 (timeline rewrite) > Message-ID: <15023171.3DjirpVA1A at pad> > Content-Type: text/plain; charset="us-ascii" > > Hello, > > I've finally finished the setup of a new PPA to test the future > Kdenlive 17.12 version, > containing a "kdenlive-test" package that can coexist with a normal > "kdenlive" package (17.04 or 17.08)... > ppa:kdenlive/kdenlive-17.12preview > > The build lives in /opt/kdenlive-test > I forgot to install an icon to a standard path, so you have to create > one or run the command: /opt/kdenlive-test/bin/kdenlive > > As usual, I publish quickly before testing seriously, so be prepared > for deception :-p > Don't hesitate to send me your remarks, and if you find it > interesting, I let you share the info on your networks (reminding > this is experimental software)... > > Vincent. > > > ------------------------------ > > Message: 3 > Date: Tue, 08 Aug 2017 14:50:15 +0200 > From: "B.M." > To: kdenlive at kde.org > Subject: Re: Hardware acceleration / vaapi > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi all, > > Well so I can expect hw accel for ENcoding to work. What's about > DEcoding? Can that be enabled as well? > > Is it correct that direct raw copying (no de- and re-encoding) is not > possible? Would be soooo nice (speedup & image quality) for all the > clips which rest unchanged! I know that this is a missing feature on > the mlt side; having a background in programming myself I know how > ugly a workaround can be, but: did you dev's discuss that in the > past? As I said, only for unchanged clips (I have 4K editing in > mind...) > > Best, > Bernd > > PS: I will see how to compile ffmpeg with hw accel enabled. > > Am 8. August 2017 14:31:13 MESZ schrieb Vincent Pinon > : >> Hello, >> >> Note that you need to have FFmpeg built with vaapi or nvenc support, >> which is not the case of Debian package. >> I don't know what's needed for Intel, but for NVidia you have to >> download a SDK linked to closed-source driver, providing personal >> information: showstopper for me (and many packagers) :\ >> >> Please let us know of any progress on your side. >> >> Evert, did you try to share your custom profiles using "HotNewStuff" >> function in Kdenlive? ;) >> >> Vincent >> >> Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : >> >> >> Hi there, Bernd. >> >> >> >> Kdenlive supports hardware encoding through custom encoding profiles. >> >> >> This is my profile for hardware hevc encoding with nvidia: >> >> >> properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac >> crf=%quality ab=%audiobitrate+'k' >> >> >> It would have been awesome if mlt and ffmpeg used the same format in >> command lines, but this is not the case. At least they are close. >> >> >> Unfortunately I only have intel cards, so I cannot test the intel >> vaapi >> acelleration for you. >> >> >> Kind regards, >> >> >> On 8 August 2017 at 10:35, B.M. wrote: >> >> >> Dear all, >> >> After some years without I'm getting back to video editing... I >> already >> searched quite a lot but it's really hard to find "realiable" >> information, so I decided to ask here: >> >> - It seems that hw accel is not available in kdenlive >> >> - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg >> can use hardware acceleration for de- and encoding. So is mlt to >> "blame" for missing hw accel. in kdenlive? >> >> - There has been a patch (bug 378832) "use of vaapi in transcoding >> and >> rendering" which seems to tackle my question. But what did it really >> change -/ what is it for? I didn't find more info on that and it's in >> kdenlive 17.04, while Debian is at 16.12. and before I compile myself >> I'd like to get more info. >> >> - Furthermore I found a thread on this list back in April "kdenlive >> and >> mlt nvenc enabled" covering the same topic but for nvidia instead of >> Intel graphics; unfortunately nobody reported back if it really >> works. >> For me it reads like the patch I mentioned above. >> >> So regarding the current state of hw accel in kdenlive I'm still >> uncertain. >> >> Thank you for your inputs. >> >> Kind regardsBernd >> >> >> Evert VorsterIsometrix Acquistion Superchief >> >> >> >> >> >> >> -------- >> [1] mailto:b-misc at gmx.ch > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 4 > Date: Tue, 08 Aug 2017 15:04:54 +0200 > From: "harald.albrecht" > To: Vincent Pinon , kdenlive at kde.org > Subject: AW: PPA to test future 17.12 (timeline rewrite) > Message-ID: > Content-Type: text/plain; charset="utf-8" > > +100 > > -------- Ursprüngliche Nachricht -------- > Von: Vincent Pinon > Datum: 08.08.17 14:47 (GMT+01:00) > An: kdenlive at kde.org > Betreff: PPA to test future 17.12 (timeline rewrite) > > Hello, > > I've finally finished the setup of a new PPA to test the future > Kdenlive 17.12 version, > containing a "kdenlive-test" package that can coexist with a normal > "kdenlive" package (17.04 or 17.08)... > ppa:kdenlive/kdenlive-17.12preview > > The build lives in /opt/kdenlive-test > I forgot to install an icon to a standard path, so you have to create > one or run the command: /opt/kdenlive-test/bin/kdenlive > > As usual, I publish quickly before testing seriously, so be prepared > for deception :-p > Don't hesitate to send me your remarks, and if you find it > interesting, I let you share the info on your networks (reminding > this is experimental software)... > > Vincent. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > kdenlive mailing list > kdenlive at kde.org > https://mail.kde.org/mailman/listinfo/kdenlive > > > ------------------------------ > > End of kdenlive Digest, Vol 34, Issue 8 > *************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Wed Aug 9 10:14:53 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Wed, 9 Aug 2017 07:14:53 -0300 Subject: [audio clicks] Please give your feedback - deadline today Message-ID: https://bugs.kde.org/show_bug.cgi?id=371849 -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From b-misc at gmx.ch Wed Aug 9 19:55:42 2017 From: b-misc at gmx.ch (B.M.) Date: Wed, 09 Aug 2017 21:55:42 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: <2475993.diM1DYiyZM@pad> References: <2475993.diM1DYiyZM@pad> Message-ID: <4952792.RWlfyjmE0S@engiadina> Hi, Coming back regarding my attempts to get encoding using vaapi-hardware acceleration to work... First, Vincent, concerning your point of ffmpeg not being compiled with vaapi enabled in Debian - well, that's correct and not correct somehow: it's not compiled with enable-vaapi, but vaapi is still working (at least in stretch), see this Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 For me, a command like ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 works fine and encoding 4K video runs about 4x faster! What I struggle with is adding these options into the rendering profile or to begin with into the rendering script. I created the rendering script which contains the line PARAMETERS_0. But how can I add these vaapi-related options? Which one goes where? Any hints are very welcome ;-) Thanks a lot. Best, Bernd On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > Hello, > > Note that you need to have FFmpeg built with vaapi or nvenc support, which > is not the case of Debian package. I don't know what's needed for Intel, > but for NVidia you have to download a SDK linked to closed-source driver, > providing personal information: showstopper for me (and many packagers) :\ > > Please let us know of any progress on your side. > > Evert, did you try to share your custom profiles using "HotNewStuff" > function in Kdenlive? ;) > > Vincent > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > Hi there, Bernd. > > > > Kdenlive supports hardware encoding through custom encoding profiles. > > > This is my profile for hardware hevc encoding with nvidia: > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac crf=%quality > ab=%audiobitrate+'k' > > > It would have been awesome if mlt and ffmpeg used the same format in command > lines, but this is not the case. At least they are close. > > > Unfortunately I only have intel cards, so I cannot test the intel vaapi > acelleration for you. > > > Kind regards, > > > On 8 August 2017 at 10:35, B.M. wrote: > > > Dear all, > > After some years without I'm getting back to video editing... I already > searched quite a lot but it's really hard to find "realiable" information, > so I decided to ask here: > > - It seems that hw accel is not available in kdenlive > > - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg can use > hardware acceleration for de- and encoding. So is mlt to "blame" for > missing hw accel. in kdenlive? > > - There has been a patch (bug 378832) "use of vaapi in transcoding and > rendering" which seems to tackle my question. But what did it really change > -/ what is it for? I didn't find more info on that and it's in kdenlive > 17.04, while Debian is at 16.12. and before I compile myself I'd like to > get more info. > > - Furthermore I found a thread on this list back in April "kdenlive and mlt > nvenc enabled" covering the same topic but for nvidia instead of Intel > graphics; unfortunately nobody reported back if it really works. For me it > reads like the patch I mentioned above. > > So regarding the current state of hw accel in kdenlive I'm still uncertain. > > Thank you for your inputs. > > Kind regardsBernd > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > -------- > [1] mailto:b-misc at gmx.ch From b-misc at gmx.ch Thu Aug 10 12:36:16 2017 From: b-misc at gmx.ch (B.M.) Date: Thu, 10 Aug 2017 14:36:16 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: References: <4952792.RWlfyjmE0S@engiadina> Message-ID: <2322302.QIteybYWNe@engiadina> Hi, Foreword: I just did the upgrade to the testing package (17.04.3) to get this "bug fix". I'm really sorry, but I don't get it: What you've sent me is the rendering parameter, as set in the render dialog. You changed is from vcodec=hevc to vcodec_nvenc to get hardware encoding working with your nvidia card. What I want is just the same, but for vaapi because I've only the integrated intel graphics. I can use libx264_vaapi as like with the ffmpeg command, but there are more parameter required (vaapie_device, hwaccel, ...) - that's what Anton mentions in his bug report, and he asks for both proxy clips and "encoding profile" which I take as rendering profile. JBM's answer and the commit are only talking about proxy clips and transcoding, not about rendering, so this leaves me unsure. From my understanding, I've the same problem as Anton: I need to inject the additional parameters needed for vaapi (but not for nvenc) for the rendering command, but so far I didn't find out how I have to do this. If I generate a render script, I get something like PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 avformat - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 real_time=-1" Now, where do I have to insert these parameter (beside changing libx264 to libx264_vaapi)? Unfortunately I don't have Anton's e-mail address, so I cannot ask him directly ;-) Best, Bernd On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: > Hi there, Bernd > > Have a look at this bug: > https://bugs.kde.org/show_bug.cgi?id=378832 > > With the fixed bug there is also an example on how to make a vaapi profile > from JBM > > Kind regards, > -Evert- > > On 9 August 2017 at 20:55, B.M. wrote: > > Hi, > > > > Coming back regarding my attempts to get encoding using vaapi-hardware > > acceleration to work... > > > > First, Vincent, concerning your point of ffmpeg not being compiled with > > vaapi > > enabled in Debian - well, that's correct and not correct somehow: it's not > > compiled with enable-vaapi, but vaapi is still working (at least in > > stretch), > > see this Debian bug > > report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 > > > > For me, a command like > > ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf > > 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 > > works fine and encoding 4K video runs about 4x faster! > > > > What I struggle with is adding these options into the rendering profile or > > to > > begin with into the rendering script. I created the rendering script which > > contains the line PARAMETERS_0. But how can I add these vaapi-related > > options? > > Which one goes where? Any hints are very welcome ;-) > > > > Thanks a lot. > > > > Best, > > Bernd > > > > On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > > > Hello, > > > > > > Note that you need to have FFmpeg built with vaapi or nvenc support, > > > > which > > > > > is not the case of Debian package. I don't know what's needed for Intel, > > > but for NVidia you have to download a SDK linked to closed-source > > > driver, > > > providing personal information: showstopper for me (and many packagers) > > : > > :\ > > : > > > Please let us know of any progress on your side. > > > > > > Evert, did you try to share your custom profiles using "HotNewStuff" > > > function in Kdenlive? ;) > > > > > > Vincent > > > > > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > > > > > > > Hi there, Bernd. > > > > > > > > > > > > Kdenlive supports hardware encoding through custom encoding profiles. > > > > > > > > > This is my profile for hardware hevc encoding with nvidia: > > > > > > > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > > > > crf=%quality > > > > > ab=%audiobitrate+'k' > > > > > > > > > It would have been awesome if mlt and ffmpeg used the same format in > > > > command > > > > > lines, but this is not the case. At least they are close. > > > > > > > > > Unfortunately I only have intel cards, so I cannot test the intel vaapi > > > acelleration for you. > > > > > > > > > Kind regards, > > > > > > > > > On 8 August 2017 at 10:35, B.M. wrote: > > > > > > > > > Dear all, > > > > > > After some years without I'm getting back to video editing... I already > > > searched quite a lot but it's really hard to find "realiable" > > > > information, > > > > > so I decided to ask here: > > > > > > - It seems that hw accel is not available in kdenlive > > > > > > - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg can > > > > use > > > > > hardware acceleration for de- and encoding. So is mlt to "blame" for > > > missing hw accel. in kdenlive? > > > > > > - There has been a patch (bug 378832) "use of vaapi in transcoding and > > > rendering" which seems to tackle my question. But what did it really > > > > change > > > > > -/ what is it for? I didn't find more info on that and it's in kdenlive > > > 17.04, while Debian is at 16.12. and before I compile myself I'd like to > > > get more info. > > > > > > - Furthermore I found a thread on this list back in April "kdenlive and > > > > mlt > > > > > nvenc enabled" covering the same topic but for nvidia instead of Intel > > > graphics; unfortunately nobody reported back if it really works. For me > > > > it > > > > > reads like the patch I mentioned above. > > > > > > So regarding the current state of hw accel in kdenlive I'm still > > > > uncertain. > > > > > Thank you for your inputs. > > > > > > Kind regardsBernd > > > > > > > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > > > > > > > > > > > > > > > -------- > > > [1] mailto:b-misc at gmx.ch From b-misc at gmx.ch Thu Aug 10 12:37:51 2017 From: b-misc at gmx.ch (B.M.) Date: Thu, 10 Aug 2017 14:37:51 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: <2322302.QIteybYWNe@engiadina> References: <2322302.QIteybYWNe@engiadina> Message-ID: <2184338.AjeLiazxKG@engiadina> PS: I'm trying something like (render script) PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 'avformat vaapi_device=/dev/dri/renderD128' - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vf='format=nv12,hwupload' vcodec=libx264_vaapi acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 real_time=-1" but it doesn't work. Best, Bernd On Donnerstag, 10. August 2017 14:36:16 CEST you wrote: > Hi, > > Foreword: I just did the upgrade to the testing package (17.04.3) to get > this "bug fix". > > I'm really sorry, but I don't get it: > > What you've sent me is the rendering parameter, as set in the render dialog. > You changed is from vcodec=hevc to vcodec_nvenc to get hardware encoding > working with your nvidia card. > > What I want is just the same, but for vaapi because I've only the integrated > intel graphics. I can use libx264_vaapi as like with the ffmpeg command, > but there are more parameter required (vaapie_device, hwaccel, ...) - > that's what Anton mentions in his bug report, and he asks for both proxy > clips and "encoding profile" which I take as rendering profile. JBM's > answer and the commit are only talking about proxy clips and transcoding, > not about rendering, so this leaves me unsure. > > From my understanding, I've the same problem as Anton: I need to inject the > additional parameters needed for vaapi (but not for nvenc) for the rendering > command, but so far I didn't find out how I have to do this. If I generate > a render script, I get something like > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 avformat > - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 > acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 real_time=-1" > > Now, where do I have to insert these parameter (beside changing libx264 to > libx264_vaapi)? > > Unfortunately I don't have Anton's e-mail address, so I cannot ask him > directly ;-) > > Best, > Bernd > > On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: > > Hi there, Bernd > > > > Have a look at this bug: > > https://bugs.kde.org/show_bug.cgi?id=378832 > > > > With the fixed bug there is also an example on how to make a vaapi profile > > from JBM > > > > Kind regards, > > -Evert- > > > > On 9 August 2017 at 20:55, B.M. wrote: > > > Hi, > > > > > > Coming back regarding my attempts to get encoding using vaapi-hardware > > > acceleration to work... > > > > > > First, Vincent, concerning your point of ffmpeg not being compiled with > > > vaapi > > > enabled in Debian - well, that's correct and not correct somehow: it's > > > not > > > compiled with enable-vaapi, but vaapi is still working (at least in > > > stretch), > > > see this Debian bug > > > report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 > > > > > > For me, a command like > > > ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf > > > 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 > > > works fine and encoding 4K video runs about 4x faster! > > > > > > What I struggle with is adding these options into the rendering profile > > > or > > > to > > > begin with into the rendering script. I created the rendering script > > > which > > > contains the line PARAMETERS_0. But how can I add these vaapi-related > > > options? > > > Which one goes where? Any hints are very welcome ;-) > > > > > > Thanks a lot. > > > > > > Best, > > > Bernd > > > > > > On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > > > > Hello, > > > > > > > > Note that you need to have FFmpeg built with vaapi or nvenc support, > > > > > > which > > > > > > > is not the case of Debian package. I don't know what's needed for > > > > Intel, > > > > but for NVidia you have to download a SDK linked to closed-source > > > > driver, > > > > providing personal information: showstopper for me (and many > > > > packagers) > > > : > > > :\ > > > : > > > > Please let us know of any progress on your side. > > > > > > > > Evert, did you try to share your custom profiles using "HotNewStuff" > > > > function in Kdenlive? ;) > > > > > > > > Vincent > > > > > > > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > > > > > > > > > > Hi there, Bernd. > > > > > > > > > > > > > > > > Kdenlive supports hardware encoding through custom encoding profiles. > > > > > > > > > > > > This is my profile for hardware hevc encoding with nvidia: > > > > > > > > > > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > > > > > > crf=%quality > > > > > > > ab=%audiobitrate+'k' > > > > > > > > > > > > It would have been awesome if mlt and ffmpeg used the same format in > > > > > > command > > > > > > > lines, but this is not the case. At least they are close. > > > > > > > > > > > > Unfortunately I only have intel cards, so I cannot test the intel > > > > vaapi > > > > acelleration for you. > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > On 8 August 2017 at 10:35, B.M. wrote: > > > > > > > > > > > > Dear all, > > > > > > > > After some years without I'm getting back to video editing... I > > > > already > > > > searched quite a lot but it's really hard to find "realiable" > > > > > > information, > > > > > > > so I decided to ask here: > > > > > > > > - It seems that hw accel is not available in kdenlive > > > > > > > > - As far as I understand kdenlive uses mlt which uses ffmpeg. ffpmeg > > > > can > > > > > > use > > > > > > > hardware acceleration for de- and encoding. So is mlt to "blame" for > > > > missing hw accel. in kdenlive? > > > > > > > > - There has been a patch (bug 378832) "use of vaapi in transcoding and > > > > rendering" which seems to tackle my question. But what did it really > > > > > > change > > > > > > > -/ what is it for? I didn't find more info on that and it's in > > > > kdenlive > > > > 17.04, while Debian is at 16.12. and before I compile myself I'd like > > > > to > > > > get more info. > > > > > > > > - Furthermore I found a thread on this list back in April "kdenlive > > > > and > > > > > > mlt > > > > > > > nvenc enabled" covering the same topic but for nvidia instead of Intel > > > > graphics; unfortunately nobody reported back if it really works. For > > > > me > > > > > > it > > > > > > > reads like the patch I mentioned above. > > > > > > > > So regarding the current state of hw accel in kdenlive I'm still > > > > > > uncertain. > > > > > > > Thank you for your inputs. > > > > > > > > Kind regardsBernd > > > > > > > > > > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------- > > > > [1] mailto:b-misc at gmx.ch From evorster at gmail.com Thu Aug 10 13:41:38 2017 From: evorster at gmail.com (Evert Vorster) Date: Thu, 10 Aug 2017 14:41:38 +0100 Subject: Hardware acceleration / vaapi In-Reply-To: <2184338.AjeLiazxKG@engiadina> References: <2322302.QIteybYWNe@engiadina> <2184338.AjeLiazxKG@engiadina> Message-ID: Hi there, Bernd Try again, but replace the "- $SOURCE_0 $TARGET_0" with "-i" Kind regards, -Evert- On 10 August 2017 at 13:37, B.M. wrote: > PS: I'm trying something like (render script) > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > 'avformat > vaapi_device=/dev/dri/renderD128' - $SOURCE_0 $TARGET_0 > properties=x264-medium > f=mp4 vf='format=nv12,hwupload' vcodec=libx264_vaapi acodec=aac g=120 > crf=23 > ab=160k preset=faster threads=1 real_time=-1" > > but it doesn't work. > > Best, > Bernd > > > On Donnerstag, 10. August 2017 14:36:16 CEST you wrote: > > Hi, > > > > Foreword: I just did the upgrade to the testing package (17.04.3) to get > > this "bug fix". > > > > I'm really sorry, but I don't get it: > > > > What you've sent me is the rendering parameter, as set in the render > dialog. > > You changed is from vcodec=hevc to vcodec_nvenc to get hardware encoding > > working with your nvidia card. > > > > What I want is just the same, but for vaapi because I've only the > integrated > > intel graphics. I can use libx264_vaapi as like with the ffmpeg command, > > but there are more parameter required (vaapie_device, hwaccel, ...) - > > that's what Anton mentions in his bug report, and he asks for both proxy > > clips and "encoding profile" which I take as rendering profile. JBM's > > answer and the commit are only talking about proxy clips and transcoding, > > not about rendering, so this leaves me unsure. > > > > From my understanding, I've the same problem as Anton: I need to inject > the > > additional parameters needed for vaapi (but not for nvenc) for the > rendering > > command, but so far I didn't find out how I have to do this. If I > generate > > a render script, I get something like > > > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > avformat > > - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 > > acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 real_time=-1" > > > > Now, where do I have to insert these parameter (beside changing libx264 > to > > libx264_vaapi)? > > > > Unfortunately I don't have Anton's e-mail address, so I cannot ask him > > directly ;-) > > > > Best, > > Bernd > > > > On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: > > > Hi there, Bernd > > > > > > Have a look at this bug: > > > https://bugs.kde.org/show_bug.cgi?id=378832 > > > > > > With the fixed bug there is also an example on how to make a vaapi > profile > > > from JBM > > > > > > Kind regards, > > > -Evert- > > > > > > On 9 August 2017 at 20:55, B.M. wrote: > > > > Hi, > > > > > > > > Coming back regarding my attempts to get encoding using > vaapi-hardware > > > > acceleration to work... > > > > > > > > First, Vincent, concerning your point of ffmpeg not being compiled > with > > > > vaapi > > > > enabled in Debian - well, that's correct and not correct somehow: > it's > > > > not > > > > compiled with enable-vaapi, but vaapi is still working (at least in > > > > stretch), > > > > see this Debian bug > > > > report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 > > > > > > > > For me, a command like > > > > ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf > > > > 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 > > > > works fine and encoding 4K video runs about 4x faster! > > > > > > > > What I struggle with is adding these options into the rendering > profile > > > > or > > > > to > > > > begin with into the rendering script. I created the rendering script > > > > which > > > > contains the line PARAMETERS_0. But how can I add these vaapi-related > > > > options? > > > > Which one goes where? Any hints are very welcome ;-) > > > > > > > > Thanks a lot. > > > > > > > > Best, > > > > Bernd > > > > > > > > On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > > > > > Hello, > > > > > > > > > > Note that you need to have FFmpeg built with vaapi or nvenc > support, > > > > > > > > which > > > > > > > > > is not the case of Debian package. I don't know what's needed for > > > > > Intel, > > > > > but for NVidia you have to download a SDK linked to closed-source > > > > > driver, > > > > > providing personal information: showstopper for me (and many > > > > > packagers) > > > > : > > > > :\ > > > > : > > > > > Please let us know of any progress on your side. > > > > > > > > > > Evert, did you try to share your custom profiles using > "HotNewStuff" > > > > > function in Kdenlive? ;) > > > > > > > > > > Vincent > > > > > > > > > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > > > > > > > > > > > > > Hi there, Bernd. > > > > > > > > > > > > > > > > > > > > Kdenlive supports hardware encoding through custom encoding > profiles. > > > > > > > > > > > > > > > This is my profile for hardware hevc encoding with nvidia: > > > > > > > > > > > > > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > > > > > > > > crf=%quality > > > > > > > > > ab=%audiobitrate+'k' > > > > > > > > > > > > > > > It would have been awesome if mlt and ffmpeg used the same format > in > > > > > > > > command > > > > > > > > > lines, but this is not the case. At least they are close. > > > > > > > > > > > > > > > Unfortunately I only have intel cards, so I cannot test the intel > > > > > vaapi > > > > > acelleration for you. > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > On 8 August 2017 at 10:35, B.M. wrote: > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > After some years without I'm getting back to video editing... I > > > > > already > > > > > searched quite a lot but it's really hard to find "realiable" > > > > > > > > information, > > > > > > > > > so I decided to ask here: > > > > > > > > > > - It seems that hw accel is not available in kdenlive > > > > > > > > > > - As far as I understand kdenlive uses mlt which uses ffmpeg. > ffpmeg > > > > > can > > > > > > > > use > > > > > > > > > hardware acceleration for de- and encoding. So is mlt to "blame" > for > > > > > missing hw accel. in kdenlive? > > > > > > > > > > - There has been a patch (bug 378832) "use of vaapi in transcoding > and > > > > > rendering" which seems to tackle my question. But what did it > really > > > > > > > > change > > > > > > > > > -/ what is it for? I didn't find more info on that and it's in > > > > > kdenlive > > > > > 17.04, while Debian is at 16.12. and before I compile myself I'd > like > > > > > to > > > > > get more info. > > > > > > > > > > - Furthermore I found a thread on this list back in April "kdenlive > > > > > and > > > > > > > > mlt > > > > > > > > > nvenc enabled" covering the same topic but for nvidia instead of > Intel > > > > > graphics; unfortunately nobody reported back if it really works. > For > > > > > me > > > > > > > > it > > > > > > > > > reads like the patch I mentioned above. > > > > > > > > > > So regarding the current state of hw accel in kdenlive I'm still > > > > > > > > uncertain. > > > > > > > > > Thank you for your inputs. > > > > > > > > > > Kind regardsBernd > > > > > > > > > > > > > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------- > > > > > [1] mailto:b-misc at gmx.ch > > > -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From b-misc at gmx.ch Thu Aug 10 18:47:47 2017 From: b-misc at gmx.ch (B.M.) Date: Thu, 10 Aug 2017 20:47:47 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: References: <2184338.AjeLiazxKG@engiadina> Message-ID: <4165579.qQgvFNZM8j@engiadina> 1) Proxy clips -- done Proxy clips creation with hardware acceleration is working fine now, for the record: I use x264 with these settings (in ~/.local/share/kdenlive/ encodingprofiles.rc): x264_vaapi=-vaapi_device /dev/dri/renderD128 -i -vf format=nv12,hwupload,scale_vaapi=w=1280:h=720 -vcodec h264_vaapi -b:v 5M -ab 128k -acodec libvorbis;mp4 2) Project rendering -- open Still open - Evert, -i instead of $SOURCE_0 and $TARGET_0 cannot work because source and target contain the mlt script and the output file. Does this not work at all? Is it a mlt problem? Thank you so much for further input! Bernd On Donnerstag, 10. August 2017 14:41:38 CEST you wrote: > Hi there, Bernd > > Try again, but replace the "- $SOURCE_0 $TARGET_0" with "-i" > > Kind regards, > -Evert- > > On 10 August 2017 at 13:37, B.M. wrote: > > PS: I'm trying something like (render script) > > > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > > 'avformat > > vaapi_device=/dev/dri/renderD128' - $SOURCE_0 $TARGET_0 > > properties=x264-medium > > f=mp4 vf='format=nv12,hwupload' vcodec=libx264_vaapi acodec=aac g=120 > > crf=23 > > ab=160k preset=faster threads=1 real_time=-1" > > > > but it doesn't work. > > > > Best, > > Bernd > > > > On Donnerstag, 10. August 2017 14:36:16 CEST you wrote: > > > Hi, > > > > > > Foreword: I just did the upgrade to the testing package (17.04.3) to get > > > this "bug fix". > > > > > > I'm really sorry, but I don't get it: > > > > > > What you've sent me is the rendering parameter, as set in the render > > > > dialog. > > > > > You changed is from vcodec=hevc to vcodec_nvenc to get hardware encoding > > > working with your nvidia card. > > > > > > What I want is just the same, but for vaapi because I've only the > > > > integrated > > > > > intel graphics. I can use libx264_vaapi as like with the ffmpeg command, > > > but there are more parameter required (vaapie_device, hwaccel, ...) - > > > that's what Anton mentions in his bug report, and he asks for both proxy > > > clips and "encoding profile" which I take as rendering profile. JBM's > > > answer and the commit are only talking about proxy clips and > > > transcoding, > > > not about rendering, so this leaves me unsure. > > > > > > From my understanding, I've the same problem as Anton: I need to inject > > > > the > > > > > additional parameters needed for vaapi (but not for nvenc) for the > > > > rendering > > > > > command, but so far I didn't find out how I have to do this. If I > > > > generate > > > > > a render script, I get something like > > > > > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > > > > avformat > > > > > - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 > > > acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 real_time=-1" > > > > > > Now, where do I have to insert these parameter (beside changing libx264 > > > > to > > > > > libx264_vaapi)? > > > > > > Unfortunately I don't have Anton's e-mail address, so I cannot ask him > > > directly ;-) > > > > > > Best, > > > Bernd > > > > > > On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: > > > > Hi there, Bernd > > > > > > > > Have a look at this bug: > > > > https://bugs.kde.org/show_bug.cgi?id=378832 > > > > > > > > With the fixed bug there is also an example on how to make a vaapi > > > > profile > > > > > > from JBM > > > > > > > > Kind regards, > > > > -Evert- > > > > > > > > On 9 August 2017 at 20:55, B.M. wrote: > > > > > Hi, > > > > > > > > > > Coming back regarding my attempts to get encoding using > > > > vaapi-hardware > > > > > > > acceleration to work... > > > > > > > > > > First, Vincent, concerning your point of ffmpeg not being compiled > > > > with > > > > > > > vaapi > > > > > > > enabled in Debian - well, that's correct and not correct somehow: > > it's > > > > > > > not > > > > > compiled with enable-vaapi, but vaapi is still working (at least in > > > > > stretch), > > > > > see this Debian bug > > > > > report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 > > > > > > > > > > For me, a command like > > > > > ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf > > > > > 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 > > > > > works fine and encoding 4K video runs about 4x faster! > > > > > > > > > > What I struggle with is adding these options into the rendering > > > > profile > > > > > > > or > > > > > to > > > > > begin with into the rendering script. I created the rendering script > > > > > which > > > > > contains the line PARAMETERS_0. But how can I add these > > > > > vaapi-related > > > > > options? > > > > > Which one goes where? Any hints are very welcome ;-) > > > > > > > > > > Thanks a lot. > > > > > > > > > > Best, > > > > > Bernd > > > > > > > > > > On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > > > > > > Hello, > > > > > > > > > > > > Note that you need to have FFmpeg built with vaapi or nvenc > > > > support, > > > > > > > which > > > > > > > > > > > is not the case of Debian package. I don't know what's needed for > > > > > > Intel, > > > > > > but for NVidia you have to download a SDK linked to closed-source > > > > > > driver, > > > > > > providing personal information: showstopper for me (and many > > > > > > packagers) > > > > > : > > > > > :\ > > > > > : > > > > > > Please let us know of any progress on your side. > > > > > > > > > > > > Evert, did you try to share your custom profiles using > > > > "HotNewStuff" > > > > > > > > function in Kdenlive? ;) > > > > > > > > > > > > Vincent > > > > > > > > > > > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > > > > > > > > > > > > > > > > Hi there, Bernd. > > > > > > > > > > > > > > > > > > > > > > > > Kdenlive supports hardware encoding through custom encoding > > > > profiles. > > > > > > > > This is my profile for hardware hevc encoding with nvidia: > > > > > > > > > > > > > > > > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > > > > > > > > > > crf=%quality > > > > > > > > > > > ab=%audiobitrate+'k' > > > > > > > > > > > > > > > > > > It would have been awesome if mlt and ffmpeg used the same format > > > > in > > > > > > > command > > > > > > > > > > > lines, but this is not the case. At least they are close. > > > > > > > > > > > > > > > > > > Unfortunately I only have intel cards, so I cannot test the intel > > > > > > vaapi > > > > > > acelleration for you. > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > On 8 August 2017 at 10:35, B.M. wrote: > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > After some years without I'm getting back to video editing... I > > > > > > already > > > > > > searched quite a lot but it's really hard to find "realiable" > > > > > > > > > > information, > > > > > > > > > > > so I decided to ask here: > > > > > > > > > > > > - It seems that hw accel is not available in kdenlive > > > > > > > > > > > > - As far as I understand kdenlive uses mlt which uses ffmpeg. > > > > ffpmeg > > > > > > > > can > > > > > > > > > > use > > > > > > > > > > > hardware acceleration for de- and encoding. So is mlt to "blame" > > > > for > > > > > > > > missing hw accel. in kdenlive? > > > > > > > > > > > > - There has been a patch (bug 378832) "use of vaapi in transcoding > > > > and > > > > > > > > rendering" which seems to tackle my question. But what did it > > > > really > > > > > > > change > > > > > > > > > > > -/ what is it for? I didn't find more info on that and it's in > > > > > > kdenlive > > > > > > 17.04, while Debian is at 16.12. and before I compile myself I'd > > > > like > > > > > > > > to > > > > > > get more info. > > > > > > > > > > > > - Furthermore I found a thread on this list back in April > > > > > > "kdenlive > > > > > > and > > > > > > > > > > mlt > > > > > > > > > > > nvenc enabled" covering the same topic but for nvidia instead of > > > > Intel > > > > > > > > graphics; unfortunately nobody reported back if it really works. > > > > For > > > > > > > > me > > > > > > > > > > it > > > > > > > > > > > reads like the patch I mentioned above. > > > > > > > > > > > > So regarding the current state of hw accel in kdenlive I'm still > > > > > > > > > > uncertain. > > > > > > > > > > > Thank you for your inputs. > > > > > > > > > > > > Kind regardsBernd > > > > > > > > > > > > > > > > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------- > > > > > > [1] mailto:b-misc at gmx.ch From evorster at gmail.com Fri Aug 11 06:24:57 2017 From: evorster at gmail.com (Evert Vorster) Date: Fri, 11 Aug 2017 07:24:57 +0100 Subject: Hardware acceleration / vaapi In-Reply-To: <4165579.qQgvFNZM8j@engiadina> References: <2184338.AjeLiazxKG@engiadina> <4165579.qQgvFNZM8j@engiadina> Message-ID: Hi there, Bernd. I am under the impression that you want to create a render profile in Kdenlive. If that is the case start with the example from the bug report: -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i -an -c:v dnxhd If you have a look at all the other rendering profiles, you will notice that none have an input our output, these are added by Kdenlive itself. Kind regards, Evert On 10 August 2017 at 19:47, B.M. wrote: > 1) Proxy clips -- done > > Proxy clips creation with hardware acceleration is working fine now, for > the > record: > I use x264 with these settings (in ~/.local/share/kdenlive/ > encodingprofiles.rc): > > x264_vaapi=-vaapi_device /dev/dri/renderD128 -i -vf > format=nv12,hwupload,scale_vaapi=w=1280:h=720 -vcodec h264_vaapi -b:v 5M > -ab > 128k -acodec libvorbis;mp4 > > > 2) Project rendering -- open > > Still open - Evert, -i instead of $SOURCE_0 and $TARGET_0 cannot work > because > source and target contain the mlt script and the output file. > Does this not work at all? Is it a mlt problem? > > Thank you so much for further input! > Bernd > > > On Donnerstag, 10. August 2017 14:41:38 CEST you wrote: > > Hi there, Bernd > > > > Try again, but replace the "- $SOURCE_0 $TARGET_0" with "-i" > > > > Kind regards, > > -Evert- > > > > On 10 August 2017 at 13:37, B.M. wrote: > > > PS: I'm trying something like (render script) > > > > > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > > > 'avformat > > > vaapi_device=/dev/dri/renderD128' - $SOURCE_0 $TARGET_0 > > > properties=x264-medium > > > f=mp4 vf='format=nv12,hwupload' vcodec=libx264_vaapi acodec=aac g=120 > > > crf=23 > > > ab=160k preset=faster threads=1 real_time=-1" > > > > > > but it doesn't work. > > > > > > Best, > > > Bernd > > > > > > On Donnerstag, 10. August 2017 14:36:16 CEST you wrote: > > > > Hi, > > > > > > > > Foreword: I just did the upgrade to the testing package (17.04.3) to > get > > > > this "bug fix". > > > > > > > > I'm really sorry, but I don't get it: > > > > > > > > What you've sent me is the rendering parameter, as set in the render > > > > > > dialog. > > > > > > > You changed is from vcodec=hevc to vcodec_nvenc to get hardware > encoding > > > > working with your nvidia card. > > > > > > > > What I want is just the same, but for vaapi because I've only the > > > > > > integrated > > > > > > > intel graphics. I can use libx264_vaapi as like with the ffmpeg > command, > > > > but there are more parameter required (vaapie_device, hwaccel, ...) - > > > > that's what Anton mentions in his bug report, and he asks for both > proxy > > > > clips and "encoding profile" which I take as rendering profile. JBM's > > > > answer and the commit are only talking about proxy clips and > > > > transcoding, > > > > not about rendering, so this leaves me unsure. > > > > > > > > From my understanding, I've the same problem as Anton: I need to > inject > > > > > > the > > > > > > > additional parameters needed for vaapi (but not for nvenc) for the > > > > > > rendering > > > > > > > command, but so far I didn't find out how I have to do this. If I > > > > > > generate > > > > > > > a render script, I get something like > > > > > > > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > > > > > > avformat > > > > > > > - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 > > > > acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 real_time=-1" > > > > > > > > Now, where do I have to insert these parameter (beside changing > libx264 > > > > > > to > > > > > > > libx264_vaapi)? > > > > > > > > Unfortunately I don't have Anton's e-mail address, so I cannot ask > him > > > > directly ;-) > > > > > > > > Best, > > > > Bernd > > > > > > > > On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: > > > > > Hi there, Bernd > > > > > > > > > > Have a look at this bug: > > > > > https://bugs.kde.org/show_bug.cgi?id=378832 > > > > > > > > > > With the fixed bug there is also an example on how to make a vaapi > > > > > > profile > > > > > > > > from JBM > > > > > > > > > > Kind regards, > > > > > -Evert- > > > > > > > > > > On 9 August 2017 at 20:55, B.M. wrote: > > > > > > Hi, > > > > > > > > > > > > Coming back regarding my attempts to get encoding using > > > > > > vaapi-hardware > > > > > > > > > acceleration to work... > > > > > > > > > > > > First, Vincent, concerning your point of ffmpeg not being > compiled > > > > > > with > > > > > > > > > vaapi > > > > > > > > > enabled in Debian - well, that's correct and not correct somehow: > > > it's > > > > > > > > > not > > > > > > compiled with enable-vaapi, but vaapi is still working (at least > in > > > > > > stretch), > > > > > > see this Debian bug > > > > > > report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 > > > > > > > > > > > > For me, a command like > > > > > > ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf > > > > > > 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 > > > > > > works fine and encoding 4K video runs about 4x faster! > > > > > > > > > > > > What I struggle with is adding these options into the rendering > > > > > > profile > > > > > > > > > or > > > > > > to > > > > > > begin with into the rendering script. I created the rendering > script > > > > > > which > > > > > > contains the line PARAMETERS_0. But how can I add these > > > > > > vaapi-related > > > > > > options? > > > > > > Which one goes where? Any hints are very welcome ;-) > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > Best, > > > > > > Bernd > > > > > > > > > > > > On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > > > > > > > Hello, > > > > > > > > > > > > > > Note that you need to have FFmpeg built with vaapi or nvenc > > > > > > support, > > > > > > > > > which > > > > > > > > > > > > > is not the case of Debian package. I don't know what's needed > for > > > > > > > Intel, > > > > > > > but for NVidia you have to download a SDK linked to > closed-source > > > > > > > driver, > > > > > > > providing personal information: showstopper for me (and many > > > > > > > packagers) > > > > > > : > > > > > > :\ > > > > > > : > > > > > > > Please let us know of any progress on your side. > > > > > > > > > > > > > > Evert, did you try to share your custom profiles using > > > > > > "HotNewStuff" > > > > > > > > > > function in Kdenlive? ;) > > > > > > > > > > > > > > Vincent > > > > > > > > > > > > > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > > > > > > > > > > > > > > > > > > > Hi there, Bernd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kdenlive supports hardware encoding through custom encoding > > > > > > profiles. > > > > > > > > > > This is my profile for hardware hevc encoding with nvidia: > > > > > > > > > > > > > > > > > > > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > > > > > > > > > > > > crf=%quality > > > > > > > > > > > > > ab=%audiobitrate+'k' > > > > > > > > > > > > > > > > > > > > > It would have been awesome if mlt and ffmpeg used the same > format > > > > > > in > > > > > > > > > command > > > > > > > > > > > > > lines, but this is not the case. At least they are close. > > > > > > > > > > > > > > > > > > > > > Unfortunately I only have intel cards, so I cannot test the > intel > > > > > > > vaapi > > > > > > > acelleration for you. > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > > > On 8 August 2017 at 10:35, B.M. wrote: > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > After some years without I'm getting back to video editing... I > > > > > > > already > > > > > > > searched quite a lot but it's really hard to find "realiable" > > > > > > > > > > > > information, > > > > > > > > > > > > > so I decided to ask here: > > > > > > > > > > > > > > - It seems that hw accel is not available in kdenlive > > > > > > > > > > > > > > - As far as I understand kdenlive uses mlt which uses ffmpeg. > > > > > > ffpmeg > > > > > > > > > > can > > > > > > > > > > > > use > > > > > > > > > > > > > hardware acceleration for de- and encoding. So is mlt to > "blame" > > > > > > for > > > > > > > > > > missing hw accel. in kdenlive? > > > > > > > > > > > > > > - There has been a patch (bug 378832) "use of vaapi in > transcoding > > > > > > and > > > > > > > > > > rendering" which seems to tackle my question. But what did it > > > > > > really > > > > > > > > > change > > > > > > > > > > > > > -/ what is it for? I didn't find more info on that and it's in > > > > > > > kdenlive > > > > > > > 17.04, while Debian is at 16.12. and before I compile myself > I'd > > > > > > like > > > > > > > > > > to > > > > > > > get more info. > > > > > > > > > > > > > > - Furthermore I found a thread on this list back in April > > > > > > > "kdenlive > > > > > > > and > > > > > > > > > > > > mlt > > > > > > > > > > > > > nvenc enabled" covering the same topic but for nvidia instead > of > > > > > > Intel > > > > > > > > > > graphics; unfortunately nobody reported back if it really > works. > > > > > > For > > > > > > > > > > me > > > > > > > > > > > > it > > > > > > > > > > > > > reads like the patch I mentioned above. > > > > > > > > > > > > > > So regarding the current state of hw accel in kdenlive I'm > still > > > > > > > > > > > > uncertain. > > > > > > > > > > > > > Thank you for your inputs. > > > > > > > > > > > > > > Kind regardsBernd > > > > > > > > > > > > > > > > > > > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------- > > > > > > > [1] mailto:b-misc at gmx.ch > > > -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From b-misc at gmx.ch Fri Aug 11 08:58:59 2017 From: b-misc at gmx.ch (B.M.) Date: Fri, 11 Aug 2017 10:58:59 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: References: <4165579.qQgvFNZM8j@engiadina> Message-ID: <27833123.GQ2C3vLgtZ@engiadina> Well, eventually I'd like to create a new render profile, but in order to find out how it works (more precisely: why it didn't work), I looked at the render scripts kdenlive creates; I thought it might be easier to learn it like that. Whatever, it doesn't work as you proposed :-( I think without support from the developers I won't make better progress. Thank you Evert, best regards, Bernd On Freitag, 11. August 2017 07:24:57 CEST Evert Vorster wrote: > Hi there, Bernd. > > I am under the impression that you want to create a render profile in > Kdenlive. If that is the case start with the example from the bug report: > > -vaapi_device /dev/dri/renderD128 -hwaccel vaapi > -hwaccel_output_format vaapi -i -an -c:v dnxhd > > If you have a look at all the other rendering profiles, you will > notice that none have an input our output, > > these are added by Kdenlive itself. > > Kind regards, > > Evert > > On 10 August 2017 at 19:47, B.M. wrote: > > 1) Proxy clips -- done > > > > Proxy clips creation with hardware acceleration is working fine now, for > > the > > record: > > I use x264 with these settings (in ~/.local/share/kdenlive/ > > encodingprofiles.rc): > > > > x264_vaapi=-vaapi_device /dev/dri/renderD128 -i -vf > > format=nv12,hwupload,scale_vaapi=w=1280:h=720 -vcodec h264_vaapi -b:v 5M > > -ab > > 128k -acodec libvorbis;mp4 > > > > > > 2) Project rendering -- open > > > > Still open - Evert, -i instead of $SOURCE_0 and $TARGET_0 cannot work > > because > > source and target contain the mlt script and the output file. > > Does this not work at all? Is it a mlt problem? > > > > Thank you so much for further input! > > Bernd > > > > On Donnerstag, 10. August 2017 14:41:38 CEST you wrote: > > > Hi there, Bernd > > > > > > Try again, but replace the "- $SOURCE_0 $TARGET_0" with "-i" > > > > > > Kind regards, > > > -Evert- > > > > > > On 10 August 2017 at 13:37, B.M. wrote: > > > > PS: I'm trying something like (render script) > > > > > > > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > > > > 'avformat > > > > vaapi_device=/dev/dri/renderD128' - $SOURCE_0 $TARGET_0 > > > > properties=x264-medium > > > > f=mp4 vf='format=nv12,hwupload' vcodec=libx264_vaapi acodec=aac g=120 > > > > crf=23 > > > > ab=160k preset=faster threads=1 real_time=-1" > > > > > > > > but it doesn't work. > > > > > > > > Best, > > > > Bernd > > > > > > > > On Donnerstag, 10. August 2017 14:36:16 CEST you wrote: > > > > > Hi, > > > > > > > > > > Foreword: I just did the upgrade to the testing package (17.04.3) to > > > > get > > > > > > > this "bug fix". > > > > > > > > > > I'm really sorry, but I don't get it: > > > > > > > > > > What you've sent me is the rendering parameter, as set in the render > > > > > > > > dialog. > > > > > > > > > You changed is from vcodec=hevc to vcodec_nvenc to get hardware > > > > encoding > > > > > > > working with your nvidia card. > > > > > > > > > > What I want is just the same, but for vaapi because I've only the > > > > > > > > integrated > > > > > > > > > intel graphics. I can use libx264_vaapi as like with the ffmpeg > > > > command, > > > > > > > but there are more parameter required (vaapie_device, hwaccel, ...) > > > > > - > > > > > that's what Anton mentions in his bug report, and he asks for both > > > > proxy > > > > > > > clips and "encoding profile" which I take as rendering profile. > > > > > JBM's > > > > > answer and the commit are only talking about proxy clips and > > > > > transcoding, > > > > > not about rendering, so this leaves me unsure. > > > > > > > > > > From my understanding, I've the same problem as Anton: I need to > > > > inject > > > > > > the > > > > > > > > > additional parameters needed for vaapi (but not for nvenc) for the > > > > > > > > rendering > > > > > > > > > command, but so far I didn't find out how I have to do this. If I > > > > > > > > generate > > > > > > > > > a render script, I get something like > > > > > > > > > > PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 > > > > > > > > avformat > > > > > > > > > - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 > > > > > acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 > > > > > real_time=-1" > > > > > > > > > > Now, where do I have to insert these parameter (beside changing > > > > libx264 > > > > > > to > > > > > > > > > libx264_vaapi)? > > > > > > > > > > Unfortunately I don't have Anton's e-mail address, so I cannot ask > > > > him > > > > > > > directly ;-) > > > > > > > > > > Best, > > > > > Bernd > > > > > > > > > > On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: > > > > > > Hi there, Bernd > > > > > > > > > > > > Have a look at this bug: > > > > > > https://bugs.kde.org/show_bug.cgi?id=378832 > > > > > > > > > > > > With the fixed bug there is also an example on how to make a vaapi > > > > > > > > profile > > > > > > > > > > from JBM > > > > > > > > > > > > Kind regards, > > > > > > -Evert- > > > > > > > > > > > > On 9 August 2017 at 20:55, B.M. wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Coming back regarding my attempts to get encoding using > > > > > > > > vaapi-hardware > > > > > > > > > > > acceleration to work... > > > > > > > > > > > > > > First, Vincent, concerning your point of ffmpeg not being > > > > compiled > > > > > > with > > > > > > > > > > > vaapi > > > > > > > > > > > enabled in Debian - well, that's correct and not correct somehow: > > > > it's > > > > > > > > > > > not > > > > > > > compiled with enable-vaapi, but vaapi is still working (at least > > > > in > > > > > > > > > stretch), > > > > > > > see this Debian bug > > > > > > > report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 > > > > > > > > > > > > > > For me, a command like > > > > > > > ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf > > > > > > > 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 > > > > > > > works fine and encoding 4K video runs about 4x faster! > > > > > > > > > > > > > > What I struggle with is adding these options into the rendering > > > > > > > > profile > > > > > > > > > > > or > > > > > > > to > > > > > > > begin with into the rendering script. I created the rendering > > > > script > > > > > > > > > which > > > > > > > contains the line PARAMETERS_0. But how can I add these > > > > > > > vaapi-related > > > > > > > options? > > > > > > > Which one goes where? Any hints are very welcome ;-) > > > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > Best, > > > > > > > Bernd > > > > > > > > > > > > > > On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: > > > > > > > > Hello, > > > > > > > > > > > > > > > > Note that you need to have FFmpeg built with vaapi or nvenc > > > > > > > > support, > > > > > > > > > > > which > > > > > > > > > > > > > > > is not the case of Debian package. I don't know what's needed > > > > for > > > > > > > > > > Intel, > > > > > > > > but for NVidia you have to download a SDK linked to > > > > closed-source > > > > > > > > > > driver, > > > > > > > > providing personal information: showstopper for me (and many > > > > > > > > packagers) > > > > > > > : > > > > > > > :\ > > > > > > > : > > > > > > > > Please let us know of any progress on your side. > > > > > > > > > > > > > > > > Evert, did you try to share your custom profiles using > > > > > > > > "HotNewStuff" > > > > > > > > > > > > function in Kdenlive? ;) > > > > > > > > > > > > > > > > Vincent > > > > > > > > > > > > > > > > Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : > > > > > > > > > > > > > > > > > > > > > > > > Hi there, Bernd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kdenlive supports hardware encoding through custom encoding > > > > > > > > profiles. > > > > > > > > > > > > This is my profile for hardware hevc encoding with nvidia: > > > > > > > > > > > > > > > > > > > > > > > > properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac > > > > > > > > > > > > > > crf=%quality > > > > > > > > > > > > > > > ab=%audiobitrate+'k' > > > > > > > > > > > > > > > > > > > > > > > > It would have been awesome if mlt and ffmpeg used the same > > > > format > > > > > > in > > > > > > > > > > > command > > > > > > > > > > > > > > > lines, but this is not the case. At least they are close. > > > > > > > > > > > > > > > > > > > > > > > > Unfortunately I only have intel cards, so I cannot test the > > > > intel > > > > > > > > > > vaapi > > > > > > > > acelleration for you. > > > > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > > > > > > > > > On 8 August 2017 at 10:35, B.M. wrote: > > > > > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > After some years without I'm getting back to video editing... > > > > > > > > I > > > > > > > > already > > > > > > > > searched quite a lot but it's really hard to find "realiable" > > > > > > > > > > > > > > information, > > > > > > > > > > > > > > > so I decided to ask here: > > > > > > > > > > > > > > > > - It seems that hw accel is not available in kdenlive > > > > > > > > > > > > > > > > - As far as I understand kdenlive uses mlt which uses ffmpeg. > > > > > > > > ffpmeg > > > > > > > > > > > > can > > > > > > > > > > > > > > use > > > > > > > > > > > > > > > hardware acceleration for de- and encoding. So is mlt to > > > > "blame" > > > > > > for > > > > > > > > > > > > missing hw accel. in kdenlive? > > > > > > > > > > > > > > > > - There has been a patch (bug 378832) "use of vaapi in > > > > transcoding > > > > > > and > > > > > > > > > > > > rendering" which seems to tackle my question. But what did it > > > > > > > > really > > > > > > > > > > > change > > > > > > > > > > > > > > > -/ what is it for? I didn't find more info on that and it's in > > > > > > > > kdenlive > > > > > > > > 17.04, while Debian is at 16.12. and before I compile myself > > > > I'd > > > > > > like > > > > > > > > > > > > to > > > > > > > > get more info. > > > > > > > > > > > > > > > > - Furthermore I found a thread on this list back in April > > > > > > > > "kdenlive > > > > > > > > and > > > > > > > > > > > > > > mlt > > > > > > > > > > > > > > > nvenc enabled" covering the same topic but for nvidia instead > > > > of > > > > > > Intel > > > > > > > > > > > > graphics; unfortunately nobody reported back if it really > > > > works. > > > > > > For > > > > > > > > > > > > me > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > reads like the patch I mentioned above. > > > > > > > > > > > > > > > > So regarding the current state of hw accel in kdenlive I'm > > > > still > > > > > > > > > uncertain. > > > > > > > > > > > > > > > Thank you for your inputs. > > > > > > > > > > > > > > > > Kind regardsBernd > > > > > > > > > > > > > > > > > > > > > > > > Evert VorsterIsometrix Acquistion Superchief > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------- > > > > > > > > [1] mailto:b-misc at gmx.ch From vpinon at kde.org Fri Aug 11 09:57:29 2017 From: vpinon at kde.org (Vincent PINON) Date: Fri, 11 Aug 2017 11:57:29 +0200 Subject: Hardware acceleration / vaapi In-Reply-To: <27833123.GQ2C3vLgtZ@engiadina> References: <4165579.qQgvFNZM8j@engiadina> <27833123.GQ2C3vLgtZ@engiadina> Message-ID: <598D7F89.6040407@kde.org> Hello, 'kdenlive_render' accepts the parameter: 'preargs="..."' to pass arguments to melt before any other (profile, consumer etc). you can also run trials with 'melt' command instead of 'kdenlive_render', which is just a wrapper to send progress info & controls to notifications, but is then a bit less flexible. (see source code in "kdenlive.git/render" : kdenlive_render.cpp, renderjob.cpp) Thanks for your investigations, very interesting if we can have it working. Sorry for not being able to help more at the moment (no linux machine nearby & quite in a hurry)... Vincent Le 08/11/2017 10:58 AM, B.M. a écrit : > Well, eventually I'd like to create a new render profile, but in order to find > out how it works (more precisely: why it didn't work), I looked at the render > scripts kdenlive creates; I thought it might be easier to learn it like that. > > Whatever, it doesn't work as you proposed :-( > > I think without support from the developers I won't make better progress. > > Thank you Evert, > best regards, > Bernd > > > On Freitag, 11. August 2017 07:24:57 CEST Evert Vorster wrote: >> Hi there, Bernd. >> >> I am under the impression that you want to create a render profile in >> Kdenlive. If that is the case start with the example from the bug report: >> >> -vaapi_device /dev/dri/renderD128 -hwaccel vaapi >> -hwaccel_output_format vaapi -i -an -c:v dnxhd >> >> If you have a look at all the other rendering profiles, you will >> notice that none have an input our output, >> >> these are added by Kdenlive itself. >> >> Kind regards, >> >> Evert >> >> On 10 August 2017 at 19:47, B.M. wrote: >>> 1) Proxy clips -- done >>> >>> Proxy clips creation with hardware acceleration is working fine now, for >>> the >>> record: >>> I use x264 with these settings (in ~/.local/share/kdenlive/ >>> encodingprofiles.rc): >>> >>> x264_vaapi=-vaapi_device /dev/dri/renderD128 -i -vf >>> format=nv12,hwupload,scale_vaapi=w=1280:h=720 -vcodec h264_vaapi -b:v 5M >>> -ab >>> 128k -acodec libvorbis;mp4 >>> >>> >>> 2) Project rendering -- open >>> >>> Still open - Evert, -i instead of $SOURCE_0 and $TARGET_0 cannot work >>> because >>> source and target contain the mlt script and the output file. >>> Does this not work at all? Is it a mlt problem? >>> >>> Thank you so much for further input! >>> Bernd >>> >>> On Donnerstag, 10. August 2017 14:41:38 CEST you wrote: >>>> Hi there, Bernd >>>> >>>> Try again, but replace the "- $SOURCE_0 $TARGET_0" with "-i" >>>> >>>> Kind regards, >>>> -Evert- >>>> >>>> On 10 August 2017 at 13:37, B.M. wrote: >>>>> PS: I'm trying something like (render script) >>>>> >>>>> PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 >>>>> 'avformat >>>>> vaapi_device=/dev/dri/renderD128' - $SOURCE_0 $TARGET_0 >>>>> properties=x264-medium >>>>> f=mp4 vf='format=nv12,hwupload' vcodec=libx264_vaapi acodec=aac g=120 >>>>> crf=23 >>>>> ab=160k preset=faster threads=1 real_time=-1" >>>>> >>>>> but it doesn't work. >>>>> >>>>> Best, >>>>> Bernd >>>>> >>>>> On Donnerstag, 10. August 2017 14:36:16 CEST you wrote: >>>>>> Hi, >>>>>> >>>>>> Foreword: I just did the upgrade to the testing package (17.04.3) to >>> get >>> >>>>>> this "bug fix". >>>>>> >>>>>> I'm really sorry, but I don't get it: >>>>>> >>>>>> What you've sent me is the rendering parameter, as set in the render >>>>> dialog. >>>>> >>>>>> You changed is from vcodec=hevc to vcodec_nvenc to get hardware >>> encoding >>> >>>>>> working with your nvidia card. >>>>>> >>>>>> What I want is just the same, but for vaapi because I've only the >>>>> integrated >>>>> >>>>>> intel graphics. I can use libx264_vaapi as like with the ffmpeg >>> command, >>> >>>>>> but there are more parameter required (vaapie_device, hwaccel, ...) >>>>>> - >>>>>> that's what Anton mentions in his bug report, and he asks for both >>> proxy >>> >>>>>> clips and "encoding profile" which I take as rendering profile. >>>>>> JBM's >>>>>> answer and the commit are only talking about proxy clips and >>>>>> transcoding, >>>>>> not about rendering, so this leaves me unsure. >>>>>> >>>>>> From my understanding, I've the same problem as Anton: I need to >>> inject >>> >>>>> the >>>>> >>>>>> additional parameters needed for vaapi (but not for nvenc) for the >>>>> rendering >>>>> >>>>>> command, but so far I didn't find out how I have to do this. If I >>>>> generate >>>>> >>>>>> a render script, I get something like >>>>>> >>>>>> PARAMETERS_0="-kuiserver -pid:8839 in=0 out=1139 $MELT uhd_2160p_25 >>>>> avformat >>>>> >>>>>> - $SOURCE_0 $TARGET_0 properties=x264-medium f=mp4 vcodec=libx264 >>>>>> acodec=aac g=120 crf=23 ab=160k preset=faster threads=1 >>>>>> real_time=-1" >>>>>> >>>>>> Now, where do I have to insert these parameter (beside changing >>> libx264 >>> >>>>> to >>>>> >>>>>> libx264_vaapi)? >>>>>> >>>>>> Unfortunately I don't have Anton's e-mail address, so I cannot ask >>> him >>> >>>>>> directly ;-) >>>>>> >>>>>> Best, >>>>>> Bernd >>>>>> >>>>>> On Donnerstag, 10. August 2017 07:54:18 CEST Evert Vorster wrote: >>>>>>> Hi there, Bernd >>>>>>> >>>>>>> Have a look at this bug: >>>>>>> https://bugs.kde.org/show_bug.cgi?id=378832 >>>>>>> >>>>>>> With the fixed bug there is also an example on how to make a vaapi >>>>> profile >>>>> >>>>>>> from JBM >>>>>>> >>>>>>> Kind regards, >>>>>>> -Evert- >>>>>>> >>>>>>> On 9 August 2017 at 20:55, B.M. wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Coming back regarding my attempts to get encoding using >>>>> vaapi-hardware >>>>> >>>>>>>> acceleration to work... >>>>>>>> >>>>>>>> First, Vincent, concerning your point of ffmpeg not being >>> compiled >>> >>>>> with >>>>> >>>>>>>> vaapi >>>>>>>> enabled in Debian - well, that's correct and not correct > somehow: >>>>> it's >>>>> >>>>>>>> not >>>>>>>> compiled with enable-vaapi, but vaapi is still working (at least >>> in >>> >>>>>>>> stretch), >>>>>>>> see this Debian bug >>>>>>>> report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830880 >>>>>>>> >>>>>>>> For me, a command like >>>>>>>> ffmpeg -vaapi_device /dev/dri/renderD128 -i infile.MP4 -vf >>>>>>>> 'format=nv12,hwupload' -c:v h264_vaapi outfile.mp4 >>>>>>>> works fine and encoding 4K video runs about 4x faster! >>>>>>>> >>>>>>>> What I struggle with is adding these options into the rendering >>>>> profile >>>>> >>>>>>>> or >>>>>>>> to >>>>>>>> begin with into the rendering script. I created the rendering >>> script >>> >>>>>>>> which >>>>>>>> contains the line PARAMETERS_0. But how can I add these >>>>>>>> vaapi-related >>>>>>>> options? >>>>>>>> Which one goes where? Any hints are very welcome ;-) >>>>>>>> >>>>>>>> Thanks a lot. >>>>>>>> >>>>>>>> Best, >>>>>>>> Bernd >>>>>>>> >>>>>>>> On Dienstag, 8. August 2017 14:31:13 CEST Vincent Pinon wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Note that you need to have FFmpeg built with vaapi or nvenc >>>>> support, >>>>> >>>>>>>> which >>>>>>>> >>>>>>>>> is not the case of Debian package. I don't know what's needed >>> for >>> >>>>>>>>> Intel, >>>>>>>>> but for NVidia you have to download a SDK linked to >>> closed-source >>> >>>>>>>>> driver, >>>>>>>>> providing personal information: showstopper for me (and many >>>>>>>>> packagers) >>>>>>>> : >>>>>>>> :\ >>>>>>>> : >>>>>>>>> Please let us know of any progress on your side. >>>>>>>>> >>>>>>>>> Evert, did you try to share your custom profiles using >>>>> "HotNewStuff" >>>>> >>>>>>>>> function in Kdenlive? ;) >>>>>>>>> >>>>>>>>> Vincent >>>>>>>>> >>>>>>>>> Le mardi 8 août 2017, 12:47:31 CEST Evert Vorster a écrit : >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi there, Bernd. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Kdenlive supports hardware encoding through custom encoding >>>>> profiles. >>>>> >>>>>>>>> This is my profile for hardware hevc encoding with nvidia: >>>>>>>>> >>>>>>>>> >>>>>>>>> properties=x265-medium f=matroska vcodec=hevc_nvenc acodec=aac >>>>>>>> crf=%quality >>>>>>>> >>>>>>>>> ab=%audiobitrate+'k' >>>>>>>>> >>>>>>>>> >>>>>>>>> It would have been awesome if mlt and ffmpeg used the same >>> format >>> >>>>> in >>>>> >>>>>>>> command >>>>>>>> >>>>>>>>> lines, but this is not the case. At least they are close. >>>>>>>>> >>>>>>>>> >>>>>>>>> Unfortunately I only have intel cards, so I cannot test the >>> intel >>> >>>>>>>>> vaapi >>>>>>>>> acelleration for you. >>>>>>>>> >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 8 August 2017 at 10:35, B.M. wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> After some years without I'm getting back to video editing... >>>>>>>>> I >>>>>>>>> already >>>>>>>>> searched quite a lot but it's really hard to find "realiable" >>>>>>>> information, >>>>>>>> >>>>>>>>> so I decided to ask here: >>>>>>>>> >>>>>>>>> - It seems that hw accel is not available in kdenlive >>>>>>>>> >>>>>>>>> - As far as I understand kdenlive uses mlt which uses ffmpeg. >>>>> ffpmeg >>>>> >>>>>>>>> can >>>>>>>> use >>>>>>>> >>>>>>>>> hardware acceleration for de- and encoding. So is mlt to >>> "blame" >>> >>>>> for >>>>> >>>>>>>>> missing hw accel. in kdenlive? >>>>>>>>> >>>>>>>>> - There has been a patch (bug 378832) "use of vaapi in >>> transcoding >>> >>>>> and >>>>> >>>>>>>>> rendering" which seems to tackle my question. But what did it >>>>> really >>>>> >>>>>>>> change >>>>>>>> >>>>>>>>> -/ what is it for? I didn't find more info on that and it's in >>>>>>>>> kdenlive >>>>>>>>> 17.04, while Debian is at 16.12. and before I compile myself >>> I'd >>> >>>>> like >>>>> >>>>>>>>> to >>>>>>>>> get more info. >>>>>>>>> >>>>>>>>> - Furthermore I found a thread on this list back in April >>>>>>>>> "kdenlive >>>>>>>>> and >>>>>>>> mlt >>>>>>>> >>>>>>>>> nvenc enabled" covering the same topic but for nvidia instead >>> of >>> >>>>> Intel >>>>> >>>>>>>>> graphics; unfortunately nobody reported back if it really >>> works. >>> >>>>> For >>>>> >>>>>>>>> me >>>>>>>> it >>>>>>>> >>>>>>>>> reads like the patch I mentioned above. >>>>>>>>> >>>>>>>>> So regarding the current state of hw accel in kdenlive I'm >>> still >>> >>>>>>>> uncertain. >>>>>>>> >>>>>>>>> Thank you for your inputs. >>>>>>>>> >>>>>>>>> Kind regardsBernd >>>>>>>>> >>>>>>>>> >>>>>>>>> Evert VorsterIsometrix Acquistion Superchief >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -------- >>>>>>>>> [1] mailto:b-misc at gmx.ch > From jesse.dubord at gmail.com Fri Aug 11 23:25:40 2017 From: jesse.dubord at gmail.com (Jesse DuBord) Date: Fri, 11 Aug 2017 16:25:40 -0700 Subject: Feedback on Kdenlive 17.04.3 after latest video project Message-ID: <1502493940.3480.11@smtp.gmail.com> Farid had requested that I make this public; hopefully JB, Vincent and the team can find this feedback helpful: ___________________________________________________________________________________________________ My experience while editing the comedic short film "50 Shades of Earl Grey" (https://www.youtube.com/watch?v=_sSIRGZnFms) with Kdenlive 17.04.3 was actually really good. It only crashed once during the 10-12 hours I was editing, which was awesome! Things I really liked: - Preview rendering was always fast. - Using the "Dublicate Clip with Speed Change" feature in the Project Bin really helped me for this project. - Being able to customize the layout is always a plus, helps workflow move like I need it to. - The "Custom Project Folder" field in the Project Settings proved to be SUPER helpful. I started this production on my primary editing desktop, and ended with the final render taking place on my laptop in Northern California. I actually keep my production projects on the Cloud for this very reason, and the transition was literally seamless: I saved on my desktop, drove to Northern California, popped open my laptop, opened the project, and finished up, without any glitches! - It was a generally solid experience. Kdenlive has come so far since the 0.8 and 0.9 series! Things I didn't like: - In the effects, some, like Rotoscoping, have an awesome keyframe layout, where others, like the Wave effect, have a very confusing keyframe layout. I would prefer all effects were keyframe-able and had a layout similar to Rotoscoping's. (see attached screenshots) - Having GPU accelleration is always a want that's been on my list for Kdenlive, and it would have helped in this project to smooth playback on clips w/ effects and decrease render time. - I still instinctively hit CTRL+S on my keyboard often during editing to save the project in the event of a crash. It would be nice to really nail down on the crashing issues, so editors aren't nervous their work is going to be lost. - I would have used the master branch for this project, but I noticed the packages for Ubuntu 16.04 LTS were no longer in the master branch -- though they used to be. With a HUGE number of users using Ubuntu LTS releases (as I recently found out on Google+), it would make sense to have the PPA's contain packages for at least the latest LTS release, in my opinion. EDITED ON: Kdenlive 17.04.3 via ppa:kdenlive/stable KDE Frameworks: 5.18.0 Qt: 5.5.1 Linux Mint 18.2 x64 (Ubuntu base) Cinnamon 3.4.6 Desktop Environment Linux kernel 4.10.0-30-generic ___________________________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Wave effect properties - Kdenlive 17043.png Type: image/png Size: 13105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Rotoscoping effect properties - Kdenlive 17043.png Type: image/png Size: 13361 bytes Desc: not available URL: From snd.noise at gmail.com Mon Aug 14 04:27:53 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Mon, 14 Aug 2017 01:27:53 -0300 Subject: kdenlive sighting in the wild Message-ID: guadec videos edited with kdenlive :) https://twitter.com/guadec/status/896396734179553280 lets put here all the times we see kdenlive in action. -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Mon Aug 14 04:39:33 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Mon, 14 Aug 2017 01:39:33 -0300 Subject: Feedback on Kdenlive 17.04.3 after latest video project In-Reply-To: <1502493940.3480.11@smtp.gmail.com> References: <1502493940.3480.11@smtp.gmail.com> Message-ID: Hi Jesse Appreciate a lot your feedback and loved the form it was done, short and objective. More people are invited to share their experience. :) 2017-08-11 20:25 GMT-03:00 Jesse DuBord : > Farid had requested that I make this public; hopefully JB, Vincent and the > team can find this feedback helpful: > ____________________________________________________________ > _______________________________________ > My experience while editing the comedic short film "50 Shades of Earl > Grey" (https://www.youtube.com/watch?v=_sSIRGZnFms) with Kdenlive 17.04.3 > was actually really good. It only crashed once during the 10-12 hours I was > editing, which was awesome! > > Things I really liked: > - Preview rendering was always fast. > - Using the "Dublicate Clip with Speed Change" feature in the Project Bin > really helped me for this project. > - Being able to customize the layout is always a plus, helps workflow move > like I need it to. > - The "Custom Project Folder" field in the Project Settings proved to be > SUPER helpful. I started this production on my primary editing desktop, and > ended with the final render taking place on my laptop in Northern > California. I actually keep my production projects on the Cloud for this > very reason, and the transition was literally seamless: I saved on my > desktop, drove to Northern California, popped open my laptop, opened the > project, and finished up, without any glitches! > - It was a generally solid experience. Kdenlive has come so far since the > 0.8 and 0.9 series! > Cool. > > Things I didn't like: > - In the effects, some, like Rotoscoping, have an awesome keyframe layout, > where others, like the Wave effect, have a very confusing keyframe layout. > I would prefer all effects were keyframe-able and had a layout similar to > Rotoscoping's. (see attached screenshots) > Good point, I have seen other effects GUI issues which should be addressed as well. Will start a phabricator thread and maybe in the future we focus a release cycle or a GOSC/SOK on this. - Having GPU accelleration is always a want that's been on my list for > Kdenlive, and it would have helped in this project to smooth playback on > clips w/ effects and decrease render time. > Looooong story.... - I still instinctively hit CTRL+S on my keyboard often during editing to > save the project in the event of a crash. It would be nice to really nail > down on the crashing issues, so editors aren't nervous their work is going > to be lost. > So what was the crash you encountered? Did you managed to reproduce it? One thing I always do is *always* run Kdenlive with GDB, that way I'll manage to catch those nasty crashes if they appear. For me I can say that it has been ages that I don't get a crash. But I am also always saving by habit. - I would have used the master branch for this project, but I noticed the > packages for Ubuntu 16.04 LTS were no longer in the master branch -- though > they used to be. With a HUGE number of users using Ubuntu LTS releases (as > I recently found out on Google+), it would make sense to have the PPA's > contain packages for at least the latest LTS release, in my opinion. > We could discuss this further in the next café. Try to join us. > > EDITED ON: > Kdenlive 17.04.3 via ppa:kdenlive/stable > KDE Frameworks: 5.18.0 > Qt: 5.5.1 > Linux Mint 18.2 x64 (Ubuntu base) > Cinnamon 3.4.6 Desktop Environment > Linux kernel 4.10.0-30-generic > So, whos's next? Cheers :D -- 1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة fsf member #5439 usuario GNU/Linux #471966 |_|0|_| |_|_|0| |0|0|0| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesse.dubord at gmail.com Tue Aug 15 00:50:28 2017 From: jesse.dubord at gmail.com (Jesse DuBord) Date: Mon, 14 Aug 2017 17:50:28 -0700 Subject: Submit patches via bug tracker? How to best go about it? Message-ID: <1502758228.2322.0@smtp.gmail.com> I added a patched file to a bug I'd reported a while back (see https://bugs.kde.org/show_bug.cgi?id=356493). The Kdenlive website said patches should be submitted via the bug tracker, yeah? Just wanted to get the proper procedure so I could make potential future patches and code contributions headache-free for the devs. Thanks guys. -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Thu Aug 17 16:51:06 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Thu, 17 Aug 2017 13:51:06 -0300 Subject: Kdenlive 17.08 is out Message-ID: https://kdenlive.org/2017/08/kdenlive-17-08-released/ -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at dodin.org Thu Aug 17 17:22:06 2017 From: jdd at dodin.org (jdd at dodin.org) Date: Thu, 17 Aug 2017 19:22:06 +0200 Subject: Kdenlive 17.08 is out In-Reply-To: References: Message-ID: <88ec4db1-3466-b10e-f022-5399c41e728d@dodin.org> Le 17/08/2017 à 18:51, farid abdelnour a écrit : > https://kdenlive.org/2017/08/kdenlive-17-08-released/ > on my openSUSE 42.2, kdenlive appimage latest crashes (but it's only 17.04.1b-x86_64). V16 works well jdd ./Kdenlive-.AppImage QEGLPlatformContext: Failed to create context: 3003 mlt_repository_init: failed to dlopen /tmp/.mount_lpslqf/usr/lib/mlt/libmltgtk2.so (/usr/lib64/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_cluster_level) trying to load "/tmp/.mount_lpslqf/plugins/kf5/kio/file.so" from "/tmp/.mount_lpslqf/plugins/kf5/kio/file.so" QEGLPlatformContext: Failed to create context: 3003 Failed to create EGL context for format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 1, profile QSurfaceFormat::OpenGLContextProfile(NoProfile)) /tmp/.mount_lpslqf/AppRun : ligne 27 : 16694 Abandon (core dumped)kdenlive --config kdenlive-appimagerc $@ -- http://dodin.org From jesse.dubord at gmail.com Thu Aug 17 17:46:04 2017 From: jesse.dubord at gmail.com (Jesse DuBord) Date: Thu, 17 Aug 2017 10:46:04 -0700 Subject: Trying to locate source code for toolbar actions? Message-ID: <1502991964.2888.0@smtp.gmail.com> I'm looking through the source code and trying to locate where the actions are for the Main and Extra toolbars (see attached image). Can anyone give me a lead? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-08-17 10-44-13.png Type: image/png Size: 567297 bytes Desc: not available URL: From jb at kdenlive.org Fri Aug 18 08:41:01 2017 From: jb at kdenlive.org (Jean-Baptiste Mardelle) Date: Fri, 18 Aug 2017 10:41:01 +0200 Subject: Trying to locate source code for toolbar actions? In-Reply-To: <1502991964.2888.0@smtp.gmail.com> References: <1502991964.2888.0@smtp.gmail.com> Message-ID: <4773c5ec-508e-5c46-d5a3-f691dc83e99b@kdenlive.org> On 17.08.2017 19:46, Jesse DuBord wrote: > I'm looking through the source code and trying to locate where the > actions are for the Main and Extra toolbars (see attached image). Can > anyone give me a lead? > Hi Jesse, You can first have a look at the src/kdenliveui.rc file. It lists most of the actions and creates the menu structure. For example, you can see the extratoolbar (at the end of kdenliveui.rc) contains an action called: project_render_button You can then make a search in the sources to fine that "project_render_button" string (it is in mainwindow.cpp). For the maintoolbar, actions are automatically added by KDE. If you want to have a custom toolbar, you must edit the kdenliveui.rc file, and add for example: This will change the main toolbar to only contain the "themes_menu" action. To make it work, you must increment the version tag at the top of the file currently something like: so you must put "150" instead. And last, it is recommanded to remove the custom toolbar settings: rm ~/.local/share/kxmlgui5/kdenlive/kdenliveui.rc Once you have done all that, recompile and install and the main toolbar should only show the actions you put in the kdenliveui.rc file Hope it helps, regards jb From uservth at krutt.org Sun Aug 20 07:51:49 2017 From: uservth at krutt.org (VTH) Date: Sun, 20 Aug 2017 07:51:49 +0000 Subject: Install Kdenlive on Void Linux? Message-ID: Hi, i have just installed Void Linux in my pc, but i still could not install Kdenlive. I tried with the AppImage, but i didnt open even giving all kind of permisions. My other options is install from Source but even if i like that the source compilation of Kdenlive has always been a pain in the ass for me and ive never could do it. Some idea.. help? Thank. From snd.noise at gmail.com Sun Aug 20 19:06:00 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Sun, 20 Aug 2017 16:06:00 -0300 Subject: Install Kdenlive on Void Linux? In-Reply-To: References: Message-ID: Hello 2017-08-20 4:51 GMT-03:00 VTH : > Hi, i have just installed Void Linux in my pc, but i still could not > install Kdenlive. > I tried with the AppImage, but i didnt open even giving all kind of > permisions. > Probably asking at your distro's forums for help on how to fix this issue, maybe there is something you need to install for AppImage to work... My other options is install from Source but even if i like that the source > compilation of Kdenlive has always been a pain in the ass for me and ive > never could do it. > Some idea.. help? > Have you seen this documentation: https://community.kde.org/Kdenlive/Development/KF5 It can probably be a bit outdated but might help. Many someone can chime in with more experience. Thank. > Cheers -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb at kdenlive.org Mon Aug 21 11:45:00 2017 From: jb at kdenlive.org (Jean-Baptiste Mardelle) Date: Mon, 21 Aug 2017 13:45:00 +0200 Subject: =?UTF-8?Q?Kdenlive_caf=c3=a9_tonight!?= Message-ID: Hi all, Just a quick reminder, we will hold our 20th Kdenlive café on IRC at 9pm (CEST): https://kdenlive.org/2017/07/kdenlive-cafe-19-and-20/ Hope to see you there! Jean-Baptiste From vpinon at kde.org Mon Aug 21 21:21:10 2017 From: vpinon at kde.org (Vincent Pinon) Date: Mon, 21 Aug 2017 23:21:10 +0200 Subject: PPA to test future 17.12 (timeline rewrite) In-Reply-To: <1502214980.3482.0@smtp.gmail.com> References: <1502214980.3482.0@smtp.gmail.com> Message-ID: <1554465.YrnZXpyjNt@pad> Hi Jesse, As explained during café (hoped to see you there ;) LTS has a tool old Qt version, and it will be quite long to repackage the Qt stack (into /opt to avoid breaking other apps) AppImages / FlatPack / Snaps could be a solution, but not ready yet, maybe after Randa in September... Or back in early KF5 times, I explained how to create a chroot to run recent distro packages: https://community.kde.org/Kdenlive/Development/KF5#Older_Linux_Distributions Only 7 months more and LTS will be up to date :\ Le mardi 8 août 2017, 10:56:20 CEST Jesse DuBord a écrit : Awesome stuff, Vincent! Appreciate the time you've taken to set all of this up. One comment: I did a poll on the Ubuntu G+ community, asking users whether they use the LTS ubuntu releases or the non-LTS. So far, over 1,090 people have voted, and a STAGGERING 71% use LTS releases on their primary machines (https://plus.google.com/+JesseDuBordFilms/posts/3VkkxrzCzZV[1]). I might encourage support for the latest LTS release for Kdenlive PPA's, in both the new timeline ppa and the master ppa (seems like LTS support is already in stable ppa). Having packages for those LTS versions would expand the use of them, drastically, based on my findings. Date: Tue, 08 Aug 2017 15:04:54 +0200 From: "harald.albrecht" To: Vincent Pinon , kdenlive at kde.org[4] Subject: AW: PPA to test future 17.12 (timeline rewrite) Message-ID: Content-Type: text/plain; charset="utf-8" +100 -------- Ursprüngliche Nachricht -------- Von: Vincent Pinon Datum: 08.08.17 14:47 (GMT+01:00) An: kdenlive at kde.org[4] Betreff: PPA to test future 17.12 (timeline rewrite) Hello, I've finally finished the setup of a new PPA to test the future Kdenlive 17.12 version, containing a "kdenlive-test" package that can coexist with a normal "kdenlive" package (17.04 or 17.08)... ppa:kdenlive/kdenlive-17.12preview The build lives in /opt/kdenlive-test I forgot to install an icon to a standard path, so you have to create one or run the command: /opt/kdenlive-test/bin/kdenlive As usual, I publish quickly before testing seriously, so be prepared for deception :-p Don't hesitate to send me your remarks, and if you find it interesting, I let you share the info on your networks (reminding this is experimental software)... Vincent. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ kdenlive mailing list kdenlive at kde.org[4] https://mail.kde.org/mailman/listinfo/kdenlive[7] ------------------------------ End of kdenlive Digest, Vol 34, Issue 8 *************************************** -------- [1] https://plus.google.com/+JesseDuBordFilms/posts/3VkkxrzCzZV [2] mailto:harald.albrecht at gmx.net [3] mailto:vpinon at kde.org [4] mailto:kdenlive at kde.org [5] mailto:pwd3l2eqiwvbo91fsmwimotx.1502197494626 at email.android.com [6] http://mail.kde.org/pipermail/kdenlive/attachments/20170808/19490131/attachment.html [7] https://mail.kde.org/mailman/listinfo/kdenlive -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesse.dubord at gmail.com Tue Aug 22 16:59:07 2017 From: jesse.dubord at gmail.com (Jesse DuBord) Date: Tue, 22 Aug 2017 09:59:07 -0700 Subject: PPA to test future 17.12 (timeline rewrite) In-Reply-To: References: Message-ID: <1503421147.2942.0@smtp.gmail.com> Thanks Vincent. I do appreciate the info', and I will be making a much more diligent effort to make it to every Cafe from here on out. I've been re-arranging my production schedule these past few months, and the changes should free me up to make it to future Cafes. :) Kdenlive plays too great a role in my work for me not to be pitching in. Cheers sir! On Tue, Aug 22, 2017 at 5:00 AM, kdenlive-request at kde.org wrote: > Send kdenlive mailing list submissions to > kdenlive at kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/kdenlive > or, via email, send a message with subject or body 'help' to > kdenlive-request at kde.org > > You can reach the person managing the list at > kdenlive-owner at kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of kdenlive digest..." > > > Today's Topics: > > 1. Re: PPA to test future 17.12 (timeline rewrite) (Vincent Pinon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Aug 2017 23:21:10 +0200 > From: Vincent Pinon > To: kdenlive at kde.org > Subject: Re: PPA to test future 17.12 (timeline rewrite) > Message-ID: <1554465.YrnZXpyjNt at pad> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Jesse, > > As explained during café (hoped to see you there ;) > LTS has a tool old Qt version, and it will be quite long to repackage > the Qt stack (into /opt to avoid breaking other apps) > AppImages / FlatPack / Snaps could be a solution, but not ready yet, > maybe after Randa in September... > Or back in early KF5 times, I explained how to create a chroot to run > recent distro packages: > https://community.kde.org/Kdenlive/Development/KF5#Older_Linux_Distributions > > Only 7 months more and LTS will be up to date :\ > > Le mardi 8 août 2017, 10:56:20 CEST Jesse DuBord a écrit : > > > Awesome stuff, Vincent! Appreciate the time you've taken to set all > of this up. > > > One comment: I did a poll on the Ubuntu G+ community, asking users > whether they use the LTS ubuntu releases or the non-LTS. So far, over > 1,090 people have voted, and a STAGGERING 71% use LTS releases on > their primary machines > (https://plus.google.com/+JesseDuBordFilms/posts/3VkkxrzCzZV[1]). I > might encourage support for the latest LTS release for Kdenlive > PPA's, in both the new timeline ppa and the master ppa (seems like > LTS support is already in stable ppa). Having packages for those LTS > versions would expand the use of them, drastically, based on my > findings. > > Date: Tue, 08 Aug 2017 15:04:54 +0200 > From: "harald.albrecht" > To: Vincent Pinon , kdenlive at kde.org[4] > Subject: AW: PPA to test future 17.12 (timeline rewrite) > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > +100 > > -------- Ursprüngliche Nachricht -------- > Von: Vincent Pinon > Datum: 08.08.17 14:47 (GMT+01:00) > An: kdenlive at kde.org[4] > Betreff: PPA to test future 17.12 (timeline rewrite) > > Hello, > > I've finally finished the setup of a new PPA to test the future > Kdenlive 17.12 version, > containing a "kdenlive-test" package that can coexist with a normal > "kdenlive" package (17.04 or 17.08)... > ppa:kdenlive/kdenlive-17.12preview > > The build lives in /opt/kdenlive-test > I forgot to install an icon to a standard path, so you have to create > one or run the command: /opt/kdenlive-test/bin/kdenlive > > As usual, I publish quickly before testing seriously, so be prepared > for deception :-p > Don't hesitate to send me your remarks, and if you find it > interesting, I let you share the info on your networks (reminding > this is experimental software)... > > Vincent. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > kdenlive mailing list > kdenlive at kde.org[4] > https://mail.kde.org/mailman/listinfo/kdenlive[7] > > > ------------------------------ > > End of kdenlive Digest, Vol 34, Issue 8 > *************************************** > > > > -------- > [1] https://plus.google.com/+JesseDuBordFilms/posts/3VkkxrzCzZV > [2] mailto:harald.albrecht at gmx.net > [3] mailto:vpinon at kde.org > [4] mailto:kdenlive at kde.org > [5] mailto:pwd3l2eqiwvbo91fsmwimotx.1502197494626 at email.android.com > [6] > http://mail.kde.org/pipermail/kdenlive/attachments/20170808/19490131/attachment.html > [7] https://mail.kde.org/mailman/listinfo/kdenlive > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > kdenlive mailing list > kdenlive at kde.org > https://mail.kde.org/mailman/listinfo/kdenlive > > > ------------------------------ > > End of kdenlive Digest, Vol 34, Issue 22 > **************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From camille.moulin at free.fr Wed Aug 23 09:20:15 2017 From: camille.moulin at free.fr (Camille Moulin) Date: Wed, 23 Aug 2017 11:20:15 +0200 Subject: Ambiguity of "clip" Message-ID: Hi all, I'm trying to debug a rather upsetting corruption issue, and doing so, I realized that the word "Clip" is used to refer to two different kind of things : footage (things you find in the project bin) or instances of such footage in the time line. I think it would be clearer to have two different terms: has this point already been discussed? Cheers, Camille From harald.albrecht at gmx.net Wed Aug 23 09:24:09 2017 From: harald.albrecht at gmx.net (Harald Albrecht) Date: Wed, 23 Aug 2017 11:24:09 +0200 Subject: Ambiguity of "clip" In-Reply-To: References: Message-ID: <536922ee-6b04-dd51-1de9-46aebb71c4a5@gmx.net> Hi, my limited understanding is that in those situations where it's necessary to be more precise, we use these terms: * (project) bin clip (...which MLT technically is a producer) * timeline clip (which is an instance in the timeline) Hope this helps, Harald Am 23.08.2017 um 11:20 schrieb Camille Moulin: > Hi all, > > I'm trying to debug a rather upsetting corruption issue, and doing so, > I realized  that the word "Clip" is used to refer to two different > kind of things : footage (things you find in the project bin) or > instances of such footage in the time line. > > I think it would be clearer to have two different terms: has this > point already been discussed? > > Cheers, > > Camille > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evorster at gmail.com Wed Aug 23 09:25:42 2017 From: evorster at gmail.com (Evert Vorster) Date: Wed, 23 Aug 2017 10:25:42 +0100 Subject: Ambiguity of "clip" In-Reply-To: References: Message-ID: Hi there, Camille. What would you suggest these be called? I suppose the term clip comes from the days where film was still on actual film, and scenes were "clipped" from a roll. In this sense, "clips" on the timeline would be the more correct term, whereas "footage" is the more correct term for the items in the project folder. Just to make things more interesting, both terms can refer to exactly the same thing... Kind regards, Evert On 23 August 2017 at 10:20, Camille Moulin wrote: > Hi all, > > I'm trying to debug a rather upsetting corruption issue, and doing so, I > realized that the word "Clip" is used to refer to two different kind of > things : footage (things you find in the project bin) or instances of such > footage in the time line. > > I think it would be clearer to have two different terms: has this point > already been discussed? > > Cheers, > > Camille > > -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From camille.moulin at free.fr Wed Aug 23 10:28:06 2017 From: camille.moulin at free.fr (Camille Moulin) Date: Wed, 23 Aug 2017 12:28:06 +0200 Subject: Ambiguity of "clip" In-Reply-To: <536922ee-6b04-dd51-1de9-46aebb71c4a5@gmx.net> References: <536922ee-6b04-dd51-1de9-46aebb71c4a5@gmx.net> Message-ID: <50251921-1c0d-2bbb-40e0-deadc4324edf@free.fr> Le 23/08/2017 à 11:24, Harald Albrecht a écrit : > > Hi, > > my limited understanding is that in those situations where it's > necessary to be more precise, we use these terms: > > * (project) bin clip (...which MLT technically is a producer) > * timeline clip (which is an instance in the timeline) > > Hope this helps, Yep, it's actually a solution for my "how to describe my issue in an understandable way" problem. Thanks, Camille -------------- next part -------------- An HTML attachment was scrubbed... URL: From camille.moulin at free.fr Wed Aug 23 11:08:28 2017 From: camille.moulin at free.fr (Camille Moulin) Date: Wed, 23 Aug 2017 13:08:28 +0200 Subject: Ambiguity of "clip" In-Reply-To: References: Message-ID: <2ff1d45f-6f53-06ab-6c35-d5bca0e959aa@free.fr> Hi Evert, Le 23/08/2017 à 11:25, Evert Vorster a écrit : > Hi there, Camille. > > What would you suggest these be called? > > I suppose the term clip comes from the days where film was still on > actual film, and scenes were "clipped" from a roll. > In this sense, "clips" on the timeline would be the more correct term, > whereas "footage" is the more correct term for the items in the > project folder. > > Just to make things more interesting, both terms can refer to exactly > the same thing... > I looked at other video editors and they also seem to have this ambiguous use of the word. So, I'm not sure there is any good and easy solution to this problem. I would personally lean toward something along the lines that you mentioned: keeping "clip" for instances in the timeline and finding something else for the bin clips (I'm not sure "footage" would fit grammatically). Cheers, Camille From french.ebook.lover at gmail.com Wed Aug 23 13:31:45 2017 From: french.ebook.lover at gmail.com (alcinos) Date: Wed, 23 Aug 2017 15:31:45 +0200 Subject: Ambiguity of "clip" In-Reply-To: <50251921-1c0d-2bbb-40e0-deadc4324edf@free.fr> References: <536922ee-6b04-dd51-1de9-46aebb71c4a5@gmx.net> <50251921-1c0d-2bbb-40e0-deadc4324edf@free.fr> Message-ID: Hi, I second Harald's answer regarding terminology. That is what we currently use in the UI as well as the code-base. What do you mean by "trying to debug"? If you are looking at the code, please be aware that we are currently in the process of rewriting the code of the timeline. That means that the bugs you are encountering are highly likely to disappear when that new code lands on the master branch. That also means that if you write a fix, it will be merged for the current bug fix release, but will go to waste for the next major release since all the old code is to be discarded. You can look at the progress of the rewrite in the branch "refactoring_timeline" of the git repository. Basic operations are already implemented and carefully tested. Do not hesitate to ask if you have any questions Cheers, Nicolas 2017-08-23 12:28 GMT+02:00 Camille Moulin : > Le 23/08/2017 à 11:24, Harald Albrecht a écrit : > > Hi, > > my limited understanding is that in those situations where it's necessary > to be more precise, we use these terms: > > - (project) bin clip (...which MLT technically is a producer) > - timeline clip (which is an instance in the timeline) > > Hope this helps, > > > Yep, it's actually a solution for my "how to describe my issue in an > understandable way" problem. > > Thanks, > Camille > -------------- next part -------------- An HTML attachment was scrubbed... URL: From camille.moulin at free.fr Wed Aug 23 15:49:31 2017 From: camille.moulin at free.fr (Camille Moulin) Date: Wed, 23 Aug 2017 17:49:31 +0200 Subject: Ambiguity of "clip" In-Reply-To: References: <536922ee-6b04-dd51-1de9-46aebb71c4a5@gmx.net> <50251921-1c0d-2bbb-40e0-deadc4324edf@free.fr> Message-ID: <6d623c06-04b1-12fe-96c2-99666df68fd2@free.fr> Hi Nicolas, Le 23/08/2017 à 15:31, alcinos a écrit : > Hi, > > I second Harald's answer regarding terminology. That is what we > currently use in the UI as well as the code-base. > > What do you mean by "trying to debug"? Just identifying the origin of the problem, not actually coding ;-) After upgrading to 17.04.3, I had a weird behaviour on a project I am working on for quite a time : when resizing certain timeline clips, they would shrink to 1 second or so ; that was linked to the fact that the matching bin clip was now considered to be shorter than its real length. Downgrading wouldn't solve the problem, but clearing cache and regenerating proxies seems to have fixed it. > If you are looking at the code, I was just looking at the file content to see if I could spot any obvious corruption: when mapping the concepts of the file to the elements of the UI, it felt strange to have the same name for two different things. It seems that some attempts have been made to solve the problem, a timeline clip is sometimes called "item" (cf. Timeline > Resize item start|end) but, as it has not been generalized, the situation is now suboptimal from an UX pov, with two different names for the same concept and one name for two different concepts. If people feel that it's something that should be addressed, I'd be happy to help. Cheers, Camille From vpinon at kde.org Wed Aug 23 16:07:11 2017 From: vpinon at kde.org (Vincent Pinon) Date: Wed, 23 Aug 2017 18:07:11 +0200 Subject: Ambiguity of "clip" In-Reply-To: <6d623c06-04b1-12fe-96c2-99666df68fd2@free.fr> References: <6d623c06-04b1-12fe-96c2-99666df68fd2@free.fr> Message-ID: <1812844.injyoWIH74@pad> Le mercredi 23 août 2017, 17:49:31 CEST Camille Moulin a écrit : > Hi Nicolas, > Le 23/08/2017 à 15:31, alcinos a écrit : > > Hi, > > > > I second Harald's answer regarding terminology. That is what we > > currently use in the UI as well as the code-base. > > > > What do you mean by "trying to debug"? > Just identifying the origin of the problem, not actually coding ;-) > After upgrading to 17.04.3, I had a weird behaviour on a project I am > working on for quite a time : when resizing certain timeline clips, they > would shrink to 1 second or so ; that was linked to the fact that the > matching bin clip was now considered to be shorter than its real length. > Downgrading wouldn't solve the problem, but clearing cache and > regenerating proxies seems to have fixed it. > > > If you are looking at the code, > I was just looking at the file content to see if I could spot any > obvious corruption: when mapping the concepts of the file to the > elements of the UI, it felt strange to have the same name for two > different things. > It seems that some attempts have been made to solve the problem, a > timeline clip is sometimes called "item" (cf. Timeline > Resize item > start|end) but, as it has not been generalized, the situation is now > suboptimal from an UX pov, with two different names for the same concept > and one name for two different concepts. > > If people feel that it's something that should be addressed, I'd be > happy to help. > > Cheers, > Camille In the code, timeline "item" classes address clips but *transitions* too. Maybe that's why there is a generic common name... From vpinon at kde.org Wed Aug 23 16:05:02 2017 From: vpinon at kde.org (Vincent Pinon) Date: Wed, 23 Aug 2017 18:05:02 +0200 Subject: Ambiguity of "clip" In-Reply-To: <2ff1d45f-6f53-06ab-6c35-d5bca0e959aa@free.fr> References: <2ff1d45f-6f53-06ab-6c35-d5bca0e959aa@free.fr> Message-ID: <8354194.lyymvLDJqP@pad> Le mercredi 23 août 2017, 13:08:28 CEST Camille Moulin a écrit : > Hi Evert, > Le 23/08/2017 à 11:25, Evert Vorster a écrit : > > Hi there, Camille. > > > > What would you suggest these be called? > > > > I suppose the term clip comes from the days where film was still on > > actual film, and scenes were "clipped" from a roll. > > In this sense, "clips" on the timeline would be the more correct term, > > whereas "footage" is the more correct term for the items in the > > project folder. > > > > Just to make things more interesting, both terms can refer to exactly > > the same thing... > > > > I looked at other video editors and they also seem to have this > ambiguous use of the word. So, I'm not sure there is any good and easy > solution to this problem. > I would personally lean toward something along the lines that you > mentioned: keeping "clip" for instances in the timeline and finding > something else for the bin clips (I'm not sure "footage" would fit > grammatically). > > Cheers, > Camille I usually speak of "source media" for the items in the project bin (as footage means only video for me, but sounds, titles, pictures etc fall into "media"). I somtimes name "cuts" the parts of media that are pasted on the timeline. I think the best is to stick to terminologies used in other established editors, so that newcomers are not surprised. Vincent From camille.moulin at free.fr Wed Aug 23 20:38:50 2017 From: camille.moulin at free.fr (Camille Moulin) Date: Wed, 23 Aug 2017 22:38:50 +0200 Subject: Ambiguity of "clip" In-Reply-To: <1812844.injyoWIH74@pad> References: <6d623c06-04b1-12fe-96c2-99666df68fd2@free.fr> <1812844.injyoWIH74@pad> Message-ID: Le 23/08/2017 à 18:07, Vincent Pinon a écrit : > [...] > In the code, timeline "item" classes address clips but *transitions* too. > Maybe that's why there is a generic common name... Ok, it makes sense then > I usually speak of "source media" for the items in the project bin > (as footage means only video for me, but sounds, titles, pictures etc fall into "media"). I think that "footage" is sometimes used in a broader acceptation (e.g. in After Effects), but if you use "media" internally, it's definitely preferable. > I think the best is to stick to terminologies used in other established editors, > so that newcomers are not surprised. +1 ; but from what I get, mainstream applications manage to have less ambiguity by having a less extensive use of the word "Clip" : e.g., in Final Cut Pro, "proxy clips" are called "proxy media". So would you think that changing (bin) "Clip" to "Media" would be useful and worth it? Cheers, Camille -------------- next part -------------- An HTML attachment was scrubbed... URL: From french.ebook.lover at gmail.com Fri Aug 25 16:45:24 2017 From: french.ebook.lover at gmail.com (alcinos) Date: Fri, 25 Aug 2017 18:45:24 +0200 Subject: Icons for new trimming operations Message-ID: Hi all, As you probably know already, the dev team is currently busy bringing a completly new timeline to life. This is currently going well, and we look forward to introducing new cool features. But new features mean new icons to refer to them, and new cursors skin. We currently have three icons corresponding to editing mode : normal, Razor, and Spacer. Spacer currently uses the same cursor as the one shown when resizing a clip (two horizontal arrows facing opposite directions). One possible improvement would be to design a new cursor for the spacer tool. Other than that, we also need icons/cursors for the new up-coming features. Here is the toolbox from premiere for inspiration: We mainly need Ripple, rolling, slip and slide. Of course, we need images that are distributed on permissive licences, because this is an opensource project. Does anyone know where we could find those ? Or alternatively has the skills to design them ? Thanks ! Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Fri Aug 25 18:36:21 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Fri, 25 Aug 2017 15:36:21 -0300 Subject: Icons for new trimming operations In-Reply-To: References: Message-ID: Hi alcinos So happy to see us getting there! I have asked for some help from the KDE-VDG people. Will try to spread it on the net as well. Would you like me to start a phabricator thread for this task? Cheers 2017-08-25 13:45 GMT-03:00 alcinos : > Hi all, > > As you probably know already, the dev team is currently busy bringing a > completly new timeline to life. > This is currently going well, and we look forward to introducing new cool > features. > > But new features mean new icons to refer to them, and new cursors skin. > We currently have three icons corresponding to editing mode : normal, > Razor, and Spacer. > > Spacer currently uses the same cursor as the one shown when resizing a > clip (two horizontal arrows facing opposite directions). One possible > improvement would be to design a new cursor for the spacer tool. > > Other than that, we also need icons/cursors for the new up-coming > features. Here is the toolbox from premiere for inspiration: > We mainly need Ripple, rolling, slip and slide. > Of course, we need images that are distributed on permissive licences, > because this is an opensource project. > > Does anyone know where we could find those ? Or alternatively has the > skills to design them ? > > Thanks ! > > Nicolas > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From french.ebook.lover at gmail.com Fri Aug 25 20:40:53 2017 From: french.ebook.lover at gmail.com (alcinos) Date: Fri, 25 Aug 2017 22:40:53 +0200 Subject: Icons for new trimming operations In-Reply-To: References: Message-ID: Hi Farid, Yes, a phabricator would be good I think. I just wanted to spread the word on the ML a bit, in case some readers have some design skills :) Cheers 2017-08-25 20:36 GMT+02:00 farid abdelnour : > Hi alcinos > > So happy to see us getting there! I have asked for some help from the > KDE-VDG people. Will try to spread it on the net as well. Would you like me > to start a phabricator thread for this task? > > Cheers > > 2017-08-25 13:45 GMT-03:00 alcinos : > >> Hi all, >> >> As you probably know already, the dev team is currently busy bringing a >> completly new timeline to life. >> This is currently going well, and we look forward to introducing new cool >> features. >> >> But new features mean new icons to refer to them, and new cursors skin. >> We currently have three icons corresponding to editing mode : normal, >> Razor, and Spacer. >> >> Spacer currently uses the same cursor as the one shown when resizing a >> clip (two horizontal arrows facing opposite directions). One possible >> improvement would be to design a new cursor for the spacer tool. >> >> Other than that, we also need icons/cursors for the new up-coming >> features. Here is the toolbox from premiere for inspiration: >> We mainly need Ripple, rolling, slip and slide. >> Of course, we need images that are distributed on permissive licences, >> because this is an opensource project. >> >> Does anyone know where we could find those ? Or alternatively has the >> skills to design them ? >> >> Thanks ! >> >> Nicolas >> >> > > > -- > 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| > gunga > tempoecoarte > atelier-labs > rede mocambos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Fri Aug 25 23:00:31 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Fri, 25 Aug 2017 20:00:31 -0300 Subject: Icons for new trimming operations In-Reply-To: References: Message-ID: Started it here: https://phabricator.kde.org/T6868 Will complete it asap, also those interested please chip in. Cheers 2017-08-25 17:40 GMT-03:00 alcinos : > Hi Farid, > > Yes, a phabricator would be good I think. I just wanted to spread the word > on the ML a bit, in case some readers have some design skills :) > > Cheers > > 2017-08-25 20:36 GMT+02:00 farid abdelnour : > >> Hi alcinos >> >> So happy to see us getting there! I have asked for some help from the >> KDE-VDG people. Will try to spread it on the net as well. Would you like me >> to start a phabricator thread for this task? >> >> Cheers >> >> 2017-08-25 13:45 GMT-03:00 alcinos : >> >>> Hi all, >>> >>> As you probably know already, the dev team is currently busy bringing a >>> completly new timeline to life. >>> This is currently going well, and we look forward to introducing new >>> cool features. >>> >>> But new features mean new icons to refer to them, and new cursors skin. >>> We currently have three icons corresponding to editing mode : normal, >>> Razor, and Spacer. >>> >>> Spacer currently uses the same cursor as the one shown when resizing a >>> clip (two horizontal arrows facing opposite directions). One possible >>> improvement would be to design a new cursor for the spacer tool. >>> >>> Other than that, we also need icons/cursors for the new up-coming >>> features. Here is the toolbox from premiere for inspiration: >>> We mainly need Ripple, rolling, slip and slide. >>> Of course, we need images that are distributed on permissive licences, >>> because this is an opensource project. >>> >>> Does anyone know where we could find those ? Or alternatively has the >>> skills to design them ? >>> >>> Thanks ! >>> >>> Nicolas >>> >>> >> >> >> -- >> 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| >> gunga >> tempoecoarte >> atelier-labs >> rede mocambos >> > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From evorster at gmail.com Sun Aug 27 10:14:33 2017 From: evorster at gmail.com (Evert Vorster) Date: Sun, 27 Aug 2017 11:14:33 +0100 Subject: Injecting metadata in rendering profile? Message-ID: Hi there. I am finally in a position to edit spherical vr video in kdenlive. To save myself an extra step, I would like to set the metadata for the video as spherical in kdenlive already. To do this in ffmpeg is pretty easy: ffmpeg -i input.mkv -metadata:s:v spherical-video=' true true equirectangular ' -acodec copy -vcodec-copy out.mkv The drawback of this approach is that it is an extra step, and involves copying the entire video. Unfortunately, everything in between < and > are stripped out of my profile by kdenlive's parser when I try to create the profile in kdenlive. How do I create an kdenlive rendering profile that is equivalent to the ffmpeg command above? Kind regards, -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Tue Aug 29 19:06:25 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Tue, 29 Aug 2017 16:06:25 -0300 Subject: question: mixed vc separate clips Message-ID: So to move forward with our decision we can ask some editing communities what they feel about each approach. The text could be something like this: "Kdenlive is a Free and Open Source video editor developed and maintained by a community of hackers and video makers. We are currently doing a code refactoring which will be taking a step forward in making our software more suitable for professional use. We'd like to hear what the editors of this community think about: Mixed audio/video clips vs Separate audio/video clips Currently we have it both ways, the editor chooses which paradigm to use but we are thinking of switching exclusively to the separate clips approach." The thing is I don't think it is very clear the explanation of mixed vs separate tracks. We need to develop the text further. Could anyone help me doing this? If we don't get quorum from other editors, another approach could be to evaluate how other video editing programs work but for that we need people with access to those tools. Massimo has a strong opinion which makes a lot of sense specially when you think about other features like the audio mixer. On the other hand having this flexibility makes Kdenlive standout. I am still undecided as I see pluses and cons from both ways. So hearing more people will help us make an informed decision, right? -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Tue Aug 29 23:17:30 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Tue, 29 Aug 2017 20:17:30 -0300 Subject: question: mixed vc separate clips In-Reply-To: References: Message-ID: I will submit this to some reddit communities to test the waters, anyone has a suggestion on the text before sending it? 2017-08-29 16:06 GMT-03:00 farid abdelnour : > So to move forward with our decision we can ask some editing communities > what they feel about each approach. The text could be something like this: > > > "Kdenlive is a Free and Open Source video editor > developed and maintained by a community of hackers and video makers. We are > currently doing a code refactoring which will be taking a step forward in > making our software more suitable for professional use. We'd like to hear > what the editors of this community think about: > > > Mixed audio/video clips vs Separate audio/video clips > > > Currently we have it both ways, the editor chooses which paradigm to use > but we are thinking of switching exclusively to the separate clips > approach." > > > The thing is I don't think it is very clear the explanation of mixed vs > separate tracks. We need to develop the text further. Could anyone help me > doing this? > > > If we don't get quorum from other editors, another approach could be to > evaluate how other video editing programs work but for that we need people > with access to those tools. > > > Massimo has a strong opinion which makes a lot of sense specially when you > think about other features like the audio mixer. On the other hand having > this flexibility makes Kdenlive standout. I am still undecided as I see > pluses and cons from both ways. So hearing more people will help us make an > informed decision, right? > > > -- > 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| > gunga > tempoecoarte > atelier-labs > rede mocambos > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From french.ebook.lover at gmail.com Tue Aug 29 23:34:40 2017 From: french.ebook.lover at gmail.com (alcinos) Date: Wed, 30 Aug 2017 01:34:40 +0200 Subject: question: mixed vc separate clips In-Reply-To: References: Message-ID: Hi Farid, Here is an developed text: "Kdenlive is a Free and Open Source video editor developed and maintained by a community of hackers and video makers. We are currently doing a code refactoring which will be taking a step forward in making our software more suitable for professional use. In the process, we are facing some critical design choices, and want to hear the opinion of the editors of the community. Currently, a clip inserted in the timeline in Kdenlive can be one of three things: video only, audio only or both audio and video. While this approach gives flexibility to the user, it is quite non-standard amongst video editing software, and may cause troubles if we try to implement some more advanced features like an audio mixer. The alternative, implemented in other softwares, is to avoid hybrid clips altogether, and only allow video only and audio only clips. Of course, in such a situation, inserting a clip from the bin to the timeline would actually create two clips on the timeline : one for the audio and one for the video. If you want to voice an opinion for one of the approaches, or outline advantages/drawbacks that we may not have thought of, we are looking forward to hearing from you!" I tried to explain more carefully what are the possibilities. Cheers Nicolas 2017-08-30 1:17 GMT+02:00 farid abdelnour : > I will submit this to some reddit communities to test the waters, anyone > has a suggestion on the text before sending it? > > > 2017-08-29 16:06 GMT-03:00 farid abdelnour : > >> So to move forward with our decision we can ask some editing communities >> what they feel about each approach. The text could be something like this: >> >> >> "Kdenlive is a Free and Open Source video editor >> developed and maintained by a community of hackers and video makers. We are >> currently doing a code refactoring which will be taking a step forward in >> making our software more suitable for professional use. We'd like to hear >> what the editors of this community think about: >> >> >> Mixed audio/video clips vs Separate audio/video clips >> >> >> Currently we have it both ways, the editor chooses which paradigm to use >> but we are thinking of switching exclusively to the separate clips >> approach." >> >> >> The thing is I don't think it is very clear the explanation of mixed vs >> separate tracks. We need to develop the text further. Could anyone help me >> doing this? >> >> >> If we don't get quorum from other editors, another approach could be to >> evaluate how other video editing programs work but for that we need people >> with access to those tools. >> >> >> Massimo has a strong opinion which makes a lot of sense specially when >> you think about other features like the audio mixer. On the other hand >> having this flexibility makes Kdenlive standout. I am still undecided as >> I see pluses and cons from both ways. So hearing more people will help us >> make an informed decision, right? >> >> >> -- >> 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| >> gunga >> tempoecoarte >> atelier-labs >> rede mocambos >> > > > > -- > 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| > gunga > tempoecoarte > atelier-labs > rede mocambos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Wed Aug 30 01:37:28 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Tue, 29 Aug 2017 22:37:28 -0300 Subject: question: mixed vc separate clips In-Reply-To: References: Message-ID: bullseye alcinos! thanks :D ps i will make a post on the website as well with the same text. 2017-08-29 20:34 GMT-03:00 alcinos : > Hi Farid, > > Here is an developed text: > "Kdenlive is a Free and Open Source video editor > developed and maintained by a community of hackers and video makers. We are > currently doing a code refactoring which will be taking a step forward in > making our software more suitable for professional use. In the process, we > are facing some critical design choices, and want to hear the opinion of > the editors of the community. > > Currently, a clip inserted in the timeline in Kdenlive can be one of three > things: video only, audio only or both audio and video. While this approach > gives flexibility to the user, it is quite non-standard amongst video > editing software, and may cause troubles if we try to implement some more > advanced features like an audio mixer. The alternative, implemented in > other softwares, is to avoid hybrid clips altogether, and only allow video > only and audio only clips. Of course, in such a situation, inserting a clip > from the bin to the timeline would actually create two clips on the > timeline : one for the audio and one for the video. > > If you want to voice an opinion for one of the approaches, or outline > advantages/drawbacks that we may not have thought of, we are looking > forward to hearing from you!" > > I tried to explain more carefully what are the possibilities. > > Cheers > Nicolas > > > 2017-08-30 1:17 GMT+02:00 farid abdelnour : > >> I will submit this to some reddit communities to test the waters, anyone >> has a suggestion on the text before sending it? >> >> >> 2017-08-29 16:06 GMT-03:00 farid abdelnour : >> >>> So to move forward with our decision we can ask some editing communities >>> what they feel about each approach. The text could be something like this: >>> >>> >>> "Kdenlive is a Free and Open Source video editor >>> developed and maintained by a community of hackers and video makers. We are >>> currently doing a code refactoring which will be taking a step forward in >>> making our software more suitable for professional use. We'd like to hear >>> what the editors of this community think about: >>> >>> >>> Mixed audio/video clips vs Separate audio/video clips >>> >>> >>> Currently we have it both ways, the editor chooses which paradigm to use >>> but we are thinking of switching exclusively to the separate clips >>> approach." >>> >>> >>> The thing is I don't think it is very clear the explanation of mixed vs >>> separate tracks. We need to develop the text further. Could anyone help me >>> doing this? >>> >>> >>> If we don't get quorum from other editors, another approach could be to >>> evaluate how other video editing programs work but for that we need people >>> with access to those tools. >>> >>> >>> Massimo has a strong opinion which makes a lot of sense specially when >>> you think about other features like the audio mixer. On the other hand >>> having this flexibility makes Kdenlive standout. I am still undecided >>> as I see pluses and cons from both ways. So hearing more people will help >>> us make an informed decision, right? >>> >>> >>> -- >>> 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| >>> gunga >>> tempoecoarte >>> atelier-labs >>> rede mocambos >>> >> >> >> >> -- >> 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| >> gunga >> tempoecoarte >> atelier-labs >> rede mocambos >> > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at dodin.org Wed Aug 30 05:43:59 2017 From: jdd at dodin.org (jdd at dodin.org) Date: Wed, 30 Aug 2017 07:43:59 +0200 Subject: question: mixed vc separate clips In-Reply-To: References: Message-ID: <71b86eb0-103a-5331-aa9c-ddf21a7235ca@dodin.org> Le 30/08/2017 à 01:34, alcinos a écrit : > If you want to voice an opinion for one of the approaches, or outline > advantages/drawbacks that we may not have thought of, we are looking > forward to hearing from you!" of course (?) the two clips created from the bin must have some sort of link to keep video and audio in sync. It's already not that easy to keep videos in sync when using the automatic audio sync between several tracks (which is one of the kdenlive strength). thanks jdd -- http://dodin.org From evorster at gmail.com Wed Aug 30 06:26:33 2017 From: evorster at gmail.com (Evert Vorster) Date: Wed, 30 Aug 2017 07:26:33 +0100 Subject: question: mixed vc separate clips In-Reply-To: <71b86eb0-103a-5331-aa9c-ddf21a7235ca@dodin.org> References: <71b86eb0-103a-5331-aa9c-ddf21a7235ca@dodin.org> Message-ID: Hi there, everybody. As a Kdenlive user, I think the opinions of Kdenlive users matter more than the opinion of the developers of other video editing software. It's only logical, surely there must be a reason that Kdenlive is the preferred editor for the users that are using it? You might be much better served with a survey to the kdenlive users on this mailing list. I, for one, do not want Kdenlive to turn into a clone of the other editors. Kind regards, -Evert Vorster- On 30 August 2017 at 06:43, jdd at dodin.org wrote: > Le 30/08/2017 à 01:34, alcinos a écrit : > > If you want to voice an opinion for one of the approaches, or outline >> advantages/drawbacks that we may not have thought of, we are looking >> forward to hearing from you!" >> > > of course (?) the two clips created from the bin must have some sort of > link to keep video and audio in sync. > > It's already not that easy to keep videos in sync when using the automatic > audio sync between several tracks (which is one of the kdenlive strength). > > thanks > jdd > -- > http://dodin.org > -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxstar at tin.it Wed Aug 30 14:02:40 2017 From: maxstar at tin.it (Massimo Stella) Date: Wed, 30 Aug 2017 16:02:40 +0200 (CEST) Subject: R: Re: question: mixed vc separate clips Message-ID: <15e33737c86.maxstar@tin.it> Hi everybody. I don't think we have to be too rigid in any choice we do and it's not the matter to be a clone or not of other software. Generally, applications are similar only for the facts that they try to use the best possible approach to make users happy when they are using the specific application. So, for me, the question is: which is the best possible approach for making Kdenlive the fastest and the easier software around? How can Kdenlive do a certain feature solve my problems in arranging complicated sequence on the timeline? The question for me is not how to make Kdenlive different but how to make Kdenlive the best in term of approach to the editing work. What I like about the current way to proceed is the fact that you can turn any clip in Audio/Video or just video or just audio (and this is very useful for recovering sync) What I dislike about the mixed approach is that when you have to produce the final audio (I'm thinking about a professional project where the timeline is always very complex) you have to rearrange all the clips in a reasonable way, so you have to check where every single chunk of audio is. Then, I want to see the mixer of an animation project with 10 video tracks and 5 audio tracks: you'll find a 15 tracks mixer with 10 empty tracks. I guess that instead of being ideologically oriented (be different, be unique, etc) we have to find pro and cons of all the approaches and find the best possible solution to make Kdenlive not just different but better. Massimo ----Messaggio originale---- Da: evorster at gmail.com Data: 30-ago-2017 8.26 A: "jdd at dodin.org" Cc: "Kdenlive" Ogg: Re: question: mixed vc separate clips Hi there, everybody. As a Kdenlive user, I think the opinions of Kdenlive users matter more than the opinion of the developers of other video editing software. It's only logical, surely there must be a reason that Kdenlive is the preferred editor for the users that are using it? You might be much better served with a survey to the kdenlive users on this mailing list. I, for one, do not want Kdenlive to turn into a clone of the other editors. Kind regards, -Evert Vorster- On 30 August 2017 at 06:43, jdd at dodin.org wrote: Le 30/08/2017 à 01:34, alcinos a écrit : If you want to voice an opinion for one of the approaches, or outline advantages/drawbacks that we may not have thought of, we are looking forward to hearing from you!" of course (?) the two clips created from the bin must have some sort of link to keep video and audio in sync. It's already not that easy to keep videos in sync when using the automatic audio sync between several tracks (which is one of the kdenlive strength). thanks jdd -- http://dodin.org -- Evert Vorster Isometrix Acquistion Superchief -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Wed Aug 30 22:02:02 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Wed, 30 Aug 2017 19:02:02 -0300 Subject: question: mixed vc separate clips In-Reply-To: References: <71b86eb0-103a-5331-aa9c-ddf21a7235ca@dodin.org> Message-ID: Hi Evert 2017-08-30 3:26 GMT-03:00 Evert Vorster : > Hi there, everybody. > > As a Kdenlive user, I think the opinions of Kdenlive users matter more > than the opinion of the developers of other video editing software. > I think all constructive opinions matter. We are actually asking editors, not developers, about the pros and cons of these editing paradigms so we can make an informed decision on how to proceed. It's only logical, surely there must be a reason that Kdenlive is the > preferred editor for the users that are using it? > > You might be much better served with a survey to the kdenlive users on > this mailing list. I, for one, do not want Kdenlive to turn into a clone of > the other editors. > Yes, please share your opinions here on the mailing list, or as others are doing on the website, in this post: https://kdenlive.org/2017/08/design-choices-ahead/ Looking forward to hear the input from everyone on this list. > Kind regards, > -Evert Vorster- > Cheers! > On 30 August 2017 at 06:43, jdd at dodin.org wrote: > >> Le 30/08/2017 à 01:34, alcinos a écrit : >> >> If you want to voice an opinion for one of the approaches, or outline >>> advantages/drawbacks that we may not have thought of, we are looking >>> forward to hearing from you!" >>> >> >> of course (?) the two clips created from the bin must have some sort of >> link to keep video and audio in sync. >> >> It's already not that easy to keep videos in sync when using the >> automatic audio sync between several tracks (which is one of the kdenlive >> strength). >> >> thanks >> jdd >> -- >> http://dodin.org >> > > > > -- > Evert Vorster > Isometrix Acquistion Superchief > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Wed Aug 30 22:04:58 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Wed, 30 Aug 2017 19:04:58 -0300 Subject: question: mixed vc separate clips In-Reply-To: <15e33737c86.maxstar@tin.it> References: <15e33737c86.maxstar@tin.it> Message-ID: Ciao Massimo, 2017-08-30 11:02 GMT-03:00 Massimo Stella : > Hi everybody. > I don't think we have to be too rigid in any choice we do and it's not the > matter to be a clone or not of other software. > Generally, applications are similar only for the facts that they try to > use the best possible approach to make users happy when they are using the > specific application. > So, for me, the question is: which is the best possible approach for > making Kdenlive the fastest and the easier software around? > How can Kdenlive do a certain feature solve my problems in arranging > complicated sequence on the timeline? > The question for me is not how to make Kdenlive different but how to make > Kdenlive the best in term of approach to the editing work. > What I like about the current way to proceed is the fact that you can turn > any clip in Audio/Video or just video or just audio (and this is very > useful for recovering sync) > What I dislike about the mixed approach is that when you have to produce > the final audio (I'm thinking about a professional project where the > timeline is always very complex) you have to rearrange all the clips in a > reasonable way, so you have to check where every single chunk of audio is. > Then, I want to see the mixer of an animation project with 10 video tracks > and 5 audio tracks: you'll find a 15 tracks mixer with 10 empty tracks. > So if we make it in a way that whenever there is a video track without audio then it wouldn't appear in the mixer, would that "fix" the issue? > I guess that instead of being ideologically oriented (be different, be > unique, etc) we have to find pro and cons of all the approaches and find > the best possible solution to make Kdenlive not just different but better. > +1 Massimo > > ----Messaggio originale---- > Da: evorster at gmail.com > Data: 30-ago-2017 8.26 > A: "jdd at dodin.org" > Cc: "Kdenlive" > Ogg: Re: question: mixed vc separate clips > > Hi there, everybody. > > As a Kdenlive user, I think the opinions of Kdenlive users matter more > than the opinion of the developers of other video editing software. > > It's only logical, surely there must be a reason that Kdenlive is the > preferred editor for the users that are using it? > > You might be much better served with a survey to the kdenlive users on > this mailing list. I, for one, do not want Kdenlive to turn into a clone of > the other editors. > > Kind regards, > -Evert Vorster- > > On 30 August 2017 at 06:43, jdd at dodin.org wrote: > >> Le 30/08/2017 à 01:34, alcinos a écrit : >> >> If you want to voice an opinion for one of the approaches, or outline >>> advantages/drawbacks that we may not have thought of, we are looking >>> forward to hearing from you!" >>> >> >> of course (?) the two clips created from the bin must have some sort of >> link to keep video and audio in sync. >> >> It's already not that easy to keep videos in sync when using the >> automatic audio sync between several tracks (which is one of the kdenlive >> strength). >> >> thanks >> jdd >> -- >> http://dodin.org >> > > > > -- > Evert Vorster > Isometrix Acquistion Superchief > > > > -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Wed Aug 30 22:11:37 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Wed, 30 Aug 2017 19:11:37 -0300 Subject: Feedback, so far. Message-ID: Hi all, So we have gotten some feedback both from reddit and at the website. At r/editors we have gotten the most interesting answer, if you'd like to comment there to further the discussion... https://www.reddit.com/r/editors/comments/6ww3n1/looking_for_feedback/ Cheers. PS Let us wait a week maybe and then try to compile the answers... what do you say? -- 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From snd.noise at gmail.com Wed Aug 30 22:27:38 2017 From: snd.noise at gmail.com (farid abdelnour) Date: Wed, 30 Aug 2017 19:27:38 -0300 Subject: Proposal for advanced trimming tools icons Message-ID: We have an icon proposal for the advanced trimming tools: https://phabricator.kde.org/T6868 What do you think? 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| gunga tempoecoarte atelier-labs rede mocambos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at dodin.org Thu Aug 31 04:58:29 2017 From: jdd at dodin.org (jdd at dodin.org) Date: Thu, 31 Aug 2017 06:58:29 +0200 Subject: question: mixed vc separate clips In-Reply-To: References: <15e33737c86.maxstar@tin.it> Message-ID: Le 31/08/2017 à 00:04, farid abdelnour a écrit : > So if we make it in a way that whenever there is a video track without > audio then it wouldn't appear in the mixer, would that "fix" the issue? > ideally, should be an option (yes, I know, I ask much :-(), simply because often the images are the best way to understand what the audio is about. It's much faster to scan images (video) than audio, for example to find where some subject is important jdd -- http://dodin.org