Hi
I´m trying to render a 2,5Minuts video, 1080, 50p but it takes about 3 hours! Editing the video works at the beginning fine but after a few minutes of work/adding transitions, text title and a panzoom effect -kdenlive is getting extremely slow so that its impossible to work with it, I have to restart my computer but after a few minutes editing its slow again. It affects also the rest of the system-when I close kdenlive-the entire system is very slow (browsing, etc) .
I´m using kdenlive 0.9.10 on opensuse 13.2 64bit. kde 4.14.8 intel i7 Q820, 20GB Ram. On the very same computer, using sonyvegas, rendering 50p is very fast.
Is there a solution for it?

Could you precise which render profile you are using?

In 0.9.10 I switched Kdenlive's default profiles to use MLT's ones, but they appear to be much slower (targeting better compression/quality).
You can edit the profile to remove "properties=[something]" setting.
eg "H.264/AAC High Profile" would become, from
properties=x264-medium g=120 crf=%quality ab=%audiobitrate+'k'
to
g=120 crf=%quality ab=%audiobitrate+'k'
then it would use libavcodec (ffmpeg) defaults which are much faster.

On the editing slowness side, there might be a memory leak in the Kdenlive/MLT/FFmpeg stack.
Which are your versions of MLT and FFmpeg (libavformat)?
To minimize the problem, you could try activating proxy clips, it takes transcoding time at the beginning but then editing is smoother...

Of course Sony Vegas is better optimized than our hobby project, even if we're doing our best

Hi
Thanks for the help!

vpinon wrote:Could you precise which render profile you are using?

I use the H.264/AAC high profile, with its default settings.

vpinon wrote:Which are your versions of MLT and FFmpeg (libavformat)?

I´ve found 3 libacformat installed:
libavformat52 0.7.16-3.1
libavformat55 2.3.6-4.2
libavformat56 2.7-1.3

vpinon wrote:Of course Sony Vegas is better optimized than our hobby project, even if we're doing our best

Actually I like Kdenlive, everything works fine, I only hope it can work smoother on my computer so I can finally say farewell to M$...

Maybe the reason of the slow kdenlive is just some missing libraries? I was looking in the wiki Installing the required libraries, so I checked if I have it installed on my computer and found out that for ex. subversion and git are missing. Then I looked at: melt -version and got this output: No LADSPA plugins were found!
Check your LADSPA_PATH environment variable.
melt 0.9.6
Copyright (C) 2002-2014 Meltytech, LLC
<http://www.mltframework.org/>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

So I guess I need to install some more stuff, is it right? I don´t really understand what and how, could you help me further?

No missing lib can slow your system (well except for the case of hardware acceleration, not the case here).
Ladspa plugins are just packs of audio effects, on debian/ubuntu it is recommended to install "swh-plugins" package, don't know on other systems. (you would just get new equalizers, companders etc)

Did you try simplified export profiles?
Other advice : if your RAM gets filled when exporting, try to use the "save script" function of export dialog, close kdenlive and then run this script from command line (or file manager)

Technical background : export process is a different job that reopens all source clips, it almost doubles memory consumption and may make your system to use swap, very slow...

Thanks for all that information.
But still, I didn´t find the right solution and I´ve no idea where the problem is, I mean, using kdenlive in that speed is not possible. I tried to reduce the amount of transitions or replace them with others, I deleted the text titles and pan&zoom effects, I copied my mts files from the memory card and used them directly from the hard disk, and of course, tried your Tips like:

vpinon wrote:You can edit the profile to remove "properties=[something]" setting.
eg "H.264/AAC High Profile" would become, from
properties=x264-medium g=120 crf=%quality ab=%audiobitrate+'k'
to
g=120 crf=%quality ab=%audiobitrate+'k'
then it would use libavcodec (ffmpeg) defaults which are much faster.

The render speed is still 3-4 hours for a 2-3 minuets video, but even before reaching the render part- kdenlive (and the rest of the computer) is getting very slow after a short while editing.
Maybe it´s a problem with the compatibility of the distro which I use? (opensuse 13.2 64bit). I thought about changing maybe to AVlinux, do You think it make sense?

I believe we have many happy OpenSuse 13.2 users, not sure switching distro will help a lot.
Regarding edit slowness, did you try enabling proxy clips? Normally it solves the issue as it transcodes source media to lighter resolution&codec to disk.
I have seen title clips causing problems for a while, maybe try creating SVG (with Inkscape or whatever) or PNG (from GIMP...) to replace them.

I believe the real_time=-1 causes the trouble which is automatically appended to the command line.
I've created a script, and manually removed this parameter from the command line, after that I've just run the script and now the CPU usage is much better, therefore the encoding is much faster.

I just wonder what side effect will kicks in

Render done. I don't see any wierd artifact. I actually quite satisfied with the result.
The questions remains. What real_time=-1 really do? According to the doc:

Set the number of processing threads and enable frame-dropping (positive) or disable frame-dropping (negative)

Disabling frame dropping in final render make sense, but it has a default "-1" value, so there must be something else (profile?) set this indirectly. This breaks down the question like this. Why this is forcefully set to -1 by the kdenlive? It forces the default value which is rather harmful than useful. Or am I missing something?

Sometimes, people including developers want to be on the safe side, hoping to reduce or avoid regressions and bug reports. It's as simple. No Illuminati here.

I did Kdenlive projects that render fine using -3, while other projects have severe frame corruption and need to be rendered using -1. For instance, the glare effect seems to trigger multithreading issues.