Hi,

unfortunately, so far I can use only 1 processing thread when editing projects in Kdenlive (rendering using multiple threads is fine, within the limitations of MLT). I regularly hit severe performance issues when working on my projects. I probably face two separate issues here, but for the moment please let me explain them together in a single post. By the way, my Kdenlive system is a core i7 ~3.8GHz with 8Gb (just slightly more than 3Gb in use with Kdenlive and loaded project).

First example: with eight video tracks, but only five of them in use at the same time, MLT crawls and take several seconds for computation instead of fractions of seconds for four composited tracks: an affine, another affine with slight zoom, a composite with a wipe method, an affine again. Clips in question are two simple svg clip (company logo and subtitle), a .png, a .mp4, and a .png again. Before that five clip zone and after it, MLT speeds up just fine and quickly composites everything at 25fps or nearly so. Strangely, even if the track with the affine with zoom in between is disabled, MLT still crawls across this zone. No further effects on the aforementioned clips. All tracks are set to opaque, so only explicit transitions involved (I hope so!). Using more than one processing thread does not help.

Second example: some video clips have a denoise effect, white balance, two bézier curves (RGB, hue) ... this also slows down MLT to a few fps, yet only 25% CPU usage. When I use more than a single processing thread, fps gets back into much better ranges, maybe 15 fps. However, as soon as I configure more than a single processing thread, editing is like editing "in the dark". For instance, selecting a clip in the timeline and pressing Home I can see the gray mark under the timecode ruler move to correctly indicate the new position. But the white triangular playhead with the vertical line does not move. It only moves when I start playing (space), then it shows the correct position. Any reposition in stop shows the grey mark moving to the correct new position, but the playhead doesn't move.

I suspect that this is a race condition that only manifests itself clearly on fast systems. I could imagine that MLT reports back the new playhead position before the UI thread had a chance to pick up the new situation, but instead seems to throw away the new position as it thinks it is stale data. Is there any chance of this ugly bug that prevents the use of multiple processing threads on fast machines getting ironed out?

PS: thank you very much for adding back in the clip reference counts. That is something that helps me keeping the overview with my projects -- the reason is that albeit I have few clips I need to use a lot of stills in between zones from these clips. Typically around 10 to 20 stills per video clip.