ttguy wrote:As to what was removed and then returned - it is is the "processing threads" option in the configure kdenlive > environment>Melt tab

i was asking why it was removed in 0.9.10 originally but now it's ok to re-add?

vpinon wrote:
The reason why this option was removed is that it used to sometimes cause problems, especially with GPU effects (but are disabled for the moment).

So that's it then? No effort being made to resolve this at all?

this post from Dan Dennedy is the resolution.

The rendering is a melt job. And Dan - as the developer of melt - has offered his advice on this. If you want to develop a superior video rendering engine be our guest.

ttguy wrote:this post from Dan Dennedy is the resolution.

The rendering is a melt job. And Dan - as the developer of melt - has offered his advice on this. If you want to develop a superior video rendering engine be our guest.

Perhaps I should have been more specific. I understand that certain operations are difficult for Melt to render and the reason for blacklisting. What I meant was why the Sunab PPA release of Kdenlive still does not have provision for setting MLT Processing threads? Or must we assume that Kdenlive is using the maximum number of processing threads unless the effects chosen are already blacklisted?

The only thing in my blacklist to start was perspective. I added keyspillm0pup and alpha0ps. I'm not using any of these, still using only one core in 0.9.10 and have again regressed to 0.9.6 in order to realize the performance lost from the upgrade.

zerofossilfuel wrote:What I meant was why the Sunab PPA release of Kdenlive still does not have provision for setting MLT Processing threads

Which Sunab PPA do you refer. He has two. The stable release one will be the 0.9.10 release from a few months back and that will not have any of the recent git changes and so will not have processing threads option back in play. But his bleeding edge PPA https://launchpad.net/~sunab/+archive/u ... enlive-svn should have it in there I would have thought. Depending on when it was last built.

Git got MLT processing threads restored 14th Nov. Sunabs PPA last built 2014-12-14 . So it should be there.

zerofossilfuel wrote:still using only one core in 0.9.10 and have again regressed to 0.9.6 in order to realize the performance lost from the upgrade.

What else regressed? Because kdenlive performance is a combo of kdenliver, melt, ffmpeg/avconv.

Also are you comparing apples and apples? Are you using CBR encoding in both versions? Because ver 0.9.10 introduces the VBR render options.

Pretty sure it's apples to apples. In 0.9.10 I always use CBR simply because I was unsure about even trying VBR. Melt is what ever is in the repos for 14.04 LTS. I've been using the Jon Severinsson ffmpeg PPA forever. Just for fun I tried avconv/avplay and saw no change.

The regression I am most unhappy about was the conscious decision someone made to take away my option to make my own choice how many cores I want to throw into the ring for rendering. I got used to much faster rendering performance without any problems and now that's gone. The only way I can get it back is to regress Kdenlive to 0.9.6 and hold there. There were other workflow changes to 0.9.10 I didn't like as well such as the default click and drag behavior on the top corners of clips from fade in/out audio to fade to/from black.

So, truth be told, I'm perfectly happy to stay right where I am with 0.9.6.

zerofossilfuel wrote:The only way I can get it back is to regress Kdenlive to 0.9.6 and hold there.

Are you sure about that? You did not reply to my earlier question about which Sunabs PPA you are using. Because that threads option should be back in his bleeding edge version.
You might get some mileage from daily builds which give you more compatible ffmpeg/melt versions in their own sandbox.

And if you are completely unhappy with the product you can always get a refund of the money you paid for it.

ttguy wrote:

zerofossilfuel wrote:The only way I can get it back is to regress Kdenlive to 0.9.6 and hold there.

Are you sure about that? You did not reply to my earlier question about which Sunabs PPA you are using. Because that threads option should be back in his bleeding edge version.
You might get some mileage from daily builds which give you more compatible ffmpeg/melt versions in their own sandbox.

And if you are completely unhappy with the product you can always get a refund of the money you paid for it.

I'm sorry. There's more than one Sunab PPA? I thought that's why it was named Sunab. I'll have to go back and look through this thread. Thanks.

And FWIW, you would be hard pressed to find anyone that supports useful open source projects like this more than I do, voting with my dollars and lobbying others to do the same. If there was someplace to vote here with dollars I would do that too. All I ask of developers in return is that they don't walk away from the project (like Patrick Balleux did from Webcam Studio) and that it moves forward, not backward.

I assume it's not possible to use the GPU for rendering. Are there any plans to approach this? Would that be a realistic goal? Would it improve rendering speed?

GPU handling will probably come back after refocatoring for 15.08 release (August then, in git a bit before).
GPU helps for working "live" with effects on full resolution video, but for rendering, effects processing is not the only contributor: not negligible, but encoding is the most time consuming (with standard / high quality settings)

I'm really looking forward to that! I didn't understand, can't the GPU speed up the encoding?

I was wondering why encoding in Kdenlive was so much slower than on Windows. I think this is why for me too.

Gotta love the features on Kdenlive
Gotta hate the bugs

Will this improve render times for h.264?

http://www.phoronix.com/scan.php?page=n ... 6-Released