Anyone uses Kdenlive on an i7 machine? Does it use all cores?

I do not have an i7, but I can comment on the ability to use all cores. The short answer is "not by default; it depends." First of all, the multimedia processing subsystem (MLT) is not very parallelized. In general, during playback, the subsystem uses 3 threads, and the GUI runs on a fourth thread. However, it will be rare for the subsystem to be completely consuming 2 cores, let alone 3, and the GUI thread is not intensive either. So, with pre-emptive multitasking, it runs comfortably with 2 cores. Now, that is with defaults.

It is possible to set an environment variable or use the Advanced section of the Clip Properties dialog to tell it to use multi-threaded decoding. Only certain codecs support it (MPEG-2, MPEG-4, and H.264) except the advanced features of AVCHD prevents FFmpeg from using multiple threads. Also, in Render, by default, it does not use multiple threads in the encoder of the codec. However, if you make a custom render profile and add "threads=2" or more you can instruct the MPEG-2, MPEG-4, H.264, or DNxHD encoder to use multiple threads. Those threads are in addition to all threads previously mentioned.

Alternatively, instead of using the Clip Properties and threads= on a render profile, you can set the environment variable MLT_AVFORMAT_THREADS=4 and make sure kdenlive can see this when you launch it - the most obvious way is to use a terminal window, export the env var, and run kdenlive from the command line. This env var applies to both the decoder and the encoder in the codecs. Then, during a Render of a simple timeline containing a single clip, this will cause it to use - if I recall correctly - 13 threads. FFmpeg will create an additional controller thread to each of the 4 medium-weight decode threads and 4 heavy-weight encoder threads, MLT will create 2 where only one is heavy-weight, and the GUI will have a thread for reporting progress, notifications, etc. There is actually a drawback to using this environment variable: (MLT_AVFORMAT_THREADS+1) decoder threads will be created for each clip on the timeline, and you can easily exhaust the maximum number of threads allowed per process. I expect to address that in the next, v0.5.0 release of MLT.

I have a C2D and it uses both cores by default.

I have i7, 860 at 2,8ghz, 8gb ram

If I render H.264 with this profile

f=mp4 hq=1 acodec=libmp3lame ab=192k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=10000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar pass=2

First pass takes about 80% of total video running time, second pass 100-115% of total running time.

If I put threads=2 to end of that profile, I get much better CPU-utilization and render is about 50% faster. BUT, it hangs in 99% and seems to hang there, some core is maxed out etc, somethings is not right.

So, whats this, and how to max power from my PC on renders?

f=mp4 hq=1 acodec=libmp3lame ab=128k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=4000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=0 crf=22

Gives me
http://www.aijaa.com/img/b/00435/5436140.png

DV-video to H.264-video three times faster than realtime.

Hell yeah!

Tne latest version of MLT (0.4.10) contains a bug fix for a segfault near the end of dual pass, multi-threaded encoding with x264. I did not see a hang, but you should give the newer version a try, just do single pass, or render to some intermediate and transcode outside Kdenlive.

In the past months two very interesting laptops emerged on the market, both with i7 - Dell Studio 1557 and HP dv6t Quad. I could snatch the Dell for 1000€ this minute, but the GPU is ATI 4570 (slighty slower than my current Nvidia 9600?). What I am interested in now is, if the i7 alone is powerful enough to edit AVCHD, without ever having to worry about VDPAU support... (HP has a Nvidia card)

No, sorry, because FFmpeg is not (yet?) able to parallelize the decoding of H.264 as used in AVCHD, but it will be able to transcode to DNxHD really fast because it does support threaded DNxHD encoding. Also, VDPAU has not proven to be hugely beneficial for decoding H.264 when the images must return to system memory for futher processing. That might improve with NVIDIA driver releases though.

I have no more issues/hangs with Kdenlive with this line, also on my previous post:
f=mp4 hq=1 acodec=libmp3lame ab=128k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=4000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=0 crf=22

It's goddamn fast and I really don't see a reason complain anymore... Plus I just got my firewire to work with Kdenlive (I just followed instructions on this site..) so I'm in a REALLY good linux video train... YEAH!