TheDiveO wrote:Time to update this thread (in the idle hope that forum visitors actually use the search function instead of boring everyone to death asking the same question he guy two posts before already asked and got answered).

The parameter Dan Dennedy mentioned is not (yet?) exposed in Kdenlive. The number of "Encoder threads" in the rendering dialog controls only the "threads" parameter of MLT.

Do not mix the "Encoder threads" settings in the rendering dialog with the "Processing threads" in Kdenlive's configure dialog, section "Environment". The latter controls the threads used in Kdenlive during editing, but not rendering. However, on fast multicore machines using more than a single Processing thread causes a the timeline cursor to not correctly update. This is probably not a problem in MLT, but instead in Kdenlive.

Holy see.are.eay.pea! I just stumbled onto this thread browsing around this morning. Referencing this problem I posted earlier, viewtopic.php?f=265&t=130837, I was running 3 processing threads in environment thinking it would help with rendering speed. Set it back to 1 and bamm! Problem solved. I did have to restart Kdenlive, though. Just applying was not enough. You may be interested in the workaround I found to free up the timeline cursor even with 3 processing threads. I'm really hoping the devs see it and it helps them solve the problem. There seems to be a race condition happening until we manually place all our ducks in a row. Then they stay in line.

BTW, MLT encoder threads are exposed in the svn v15.13.0 by clicking "More options"

The issue with MLT threads for Kdenlive UI is documented here: https://bugs.kde.org/show_bug.cgi?id=352489

Good read. Thanks.

BTW, I have wrote a bash script that'll take a Kdenlvie render script and, split that into multiplu chunks, render them in parallel and concatenate using ffmpeg:

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

You can saturate your CPU usage pretty easily with this.

unfa is the man!

I tried your script on my old core i-5 four core cpu. I set it to 3 threads. All 4 cores were used.
I rendered out a 1920x1080 mp4 using 2 cameras, and 2 audio recorders.
It did about 6GB/hour. The video rendered in about 3 hours instead of maybe 11 hours.

This version 1.0 script did have a flaw.
The final step uses ffmpeg with a concat file to stitch the final mp4 together.

Code: Select all

ffmpeg -f concat -i list.txt -c copy "$TARGET" # merge the individual files into one

The Concat file only contains the filename without the full path. So if the scripts aren't in the render file directory it fails the last step. Then you have to run that last line manually either fixing list.txt or copying the file to the render directory.

Kdenlive definitely needs to add this script until a more seamless integrated answer can be found. It will take a lot of pressure off the devs with people complaining about wasted cpu cycles and long render times.

Thanks again unfa.