I'm using Kdenlive for almost three years and only yesterday It seemed to me that Kdenlive is using only one of the two cores of my AMD Athlon64 x2 6000+ cpu. Both during playback of a clip on the timeline and during rendering "System monitor" is showing one core almost always at 100% and the other one moving between 5% and 15% max. I'm using Kdenlive SVN repository (0.7.9 SVN).
Could it be possible? What can I do? Is there a way to fix it?
I did a screencast but "recordmydesktop" changed too much the usage of the "free" core so it was not a good test... I' ll post a screenshot as soon as possible and eventually I'll film the PC screen with my cam.
Ignazio

AFAIK kdenlive is single threaded, you won't get any boost from extra cpu's. Some codecs may benefit from multiple cores/cpu's, almost only using encoding, not while encoding. Some codecs cannot utilise more than one core anyway.

Kdenlive and MLT are not single-threaded, and rendering will most certainly use multiple cores. However, if you are using something easy to decode, little effects, and encoding to something heavy like H.264, then you might see this because the encoder is so slow holding back the video decoding and processing. MLT can and does "render ahead" of the encoding. However, it is throttled so as to not consume all your memory. See this thread for information for more explanation and forthcoming parallel processing:
http://www.kdenlive.org/forum/mts-editing-kdenlive

In the meantime, you can try to increase the speed of the H.264 encoder by customizing a profile and adding " threads=2" to the end of the Parameters. It tells x264 to use 2 threads. Some people have reported it not working, but I have not been able to reproduce that. It may not be completely obvious it is working by fully saturating both of your cores, but if you time two renders with and without that, the render with threads=2 should come out ahead. If not, it is possible x264 and ffmpeg were compiled without pthreads.

Likewise, if you are doing heavy decoding and processing, but fairly simple encoding like MPEG-2 or MPEG-4, the bottleneck is the decoding and processing holding back the encoder, and you need to wait for the new parallel processing in the next releases of MLT and Kdenlive.

I hope my responses to these 2 threads have helped people understand.

Thank you for yor reply, Dan. I think I understood. In fact, when I edit I use DNxHD and render back to DNxHD, wich is a lot faster than H.264... Maybe that's why it uses mostly one core... I don't use H.264 anymore (x264) because it takes forever... For the internet I use to import the DNxHD file created with Kdenlive in "Handbrake" and render to mpeg-4 (ffmpeg) and use the GREAT "decomb" option (it applies a modified YADIF only where it sees interlaced fields). BTW, excuse me if I go off topic but, do you think that this kind of "smart yadif" could be (easily) implemented? I know you developers have a lot to do and did an enormous work so far, but, you know, just a question ;-)
Thanks again,
Ignazio

DNxHD encoder also supports "threads=2"
Can't do the smart yadif in the forsee-able future. Yadif already works well and there is a lot to do.

Ok, thanks a lot, I'll try it. Nevermind for the smart yadif, Kdenlive for me is great just as it is!!! I'll tell you more, it goes well beyond my needs! I'm using it since early 2008...