im experiencing the same problem in Arch, i'm running
kdenlive-git v0.9.10.r13.g5e5e462-1
mlt-git v0.9.2.r119.g3d96fa5-1
ffmpeg 1:2.4.3-1
frei0r-plugins 1.4-2

changing the threads to 2, 3, or 4 has no effect. I even created a new mp4 profile which has

Code: Select all

properties=x264-medium vb=%bitrate+'k' pass=%passes ab=%audiobitrate+'k' threads=4

and it still only uses 1 core

bump

I concur - since upgrading to 0.9.10, I too seem to be unable to use the number of cores specified in the "Encoder threads" option. And though I can't prove it, my symtoms (identical to those of zerofossilfuel) would seem to imply that I'm getting two-pass rendering even though I'm not specifying it.

Using Linux Mint 17 (based on Ubuntu trusty) with kdenlive 0.9.10 from sunab ppa.

Hopefully a fix will be forthcoming...

I am also getting the same behavior as zerofossilfuel, but I was getting this behavior on 0.9.8 as well as current 0.9.10. Its just much worse now on 0.9.10.

I cannot believe we few are the only ones experiencing this problem but we certainly are among the few who noticed that it is in fact a problem. Even our moderator did not notice until it was brought to his attention. Personally, I think the problem is something deep inside the new kernel that changed the way multi-threading is delegated, a moving target that some apps, Kdenlive included, have not adjusted to. 14.04 still has bugs and regressions that IMHO should have been preventable.

Kdenlive does very little in rendering process, even MLT on the encoding side is delegating everything to libavcodec (forwarding the "threads" parameter).
Is transcoding through ffmpeg/avconv also slower? (I believe this is also the tendency)
If the encoder doesn't fill the CPU, it can mean there is a bottleneck at providing the frames (decoding, applying effects and transitions...)

Rendering speed is not my primary concern (as I am not editing intensely, launching final renders overnights), but quality and reliability.

I can now shed some real light on this problem. Nothing I was doing had any effect on processor load/rendering speed.

I disabled the Sunab PPA, purged and reinstalled. This regressed from 0.9.10 back to 0.9.6. Under the MLT environment tab I now have an option to select up to 3 Processing threads. It states ">1 experimental". The maximum on my machine is 3. I presume that is calculated from my 4 cores -1. If I had 4 cores with HTT I wonder if that number would be 7?

In any event, I bumped it up to 3, et Voi La! Nearly full CPU utilization and 2x the rendering speed. Which now begs the question, why was this option omited in the newer versions??? I am locking it down at 0.9.6 until I get a satisfactory answer.

P.S. Even in 0.9.6, adjusting the number of Encoder threads under the Render Project tab has no effect whatsoever on processor utilization/rendering speed. I set it from 4 back down to 1 and it made no difference. Only the Processor thread setting in the MLT environment tab has any effect.

MLT processing threads are restored in git master for 3 days, but sunab packages are not yet updated(?!).
Daily builds from Meltytech.com should be up to date.

The reason why this option was removed is that it used to sometimes cause problems, especially with GPU effects (but are disabled for the moment).

Your tests with the ones on the related thread viewtopic.php?f=272&t=123583&p=324353#p324353 seem to show that MLT processing tend to be limiting in several cases. What effects / transitions are you using? Color corrections, alpha compositions or large text clips may be slowing down the frames creations...
Thanks for your analysis!

I regularly use affine to watermark my entire video as well as photo overlays so that the watermark continues to show, composite transitions, audio fade in/fade out, keyframeable volume, etc. Very little in the way of fancy special effects.

I had heard from a source outside of KDENLive that the reason MLT multicore was removed is that it was just broken on too many things. For example, doing any kind of alpha operations with multi-core rendering caused massive graphical glitches. Here's an example of what I'm talking about. https://www.youtube.com/watch?v=vM-lrHTmtPQ. Running the encode with only 1 MLT core made the issue go away.

This still does not explain why single pass h264 encoding appears to be doing a 2 pass encoding, one with all allocated processors, and one with only 1 processor. Its been bugging me for awhile because rendering used to be much quicker.

jkolodziej wrote:I had heard from a source outside of KDENLive that the reason MLT multicore was removed is that it was just broken on too many things. For example, doing any kind of alpha operations with multi-core rendering caused massive graphical glitches. Here's an example of what I'm talking about. https://www.youtube.com/watch?v=vM-lrHTmtPQ. Running the encode with only 1 MLT core made the issue go away.

Wow. I see what you mean. I wonder of that's been fixed?

jkolodziej wrote:I had heard from a source outside of KDENLive that the reason MLT multicore was removed is that it was just broken on too many things.

"Too many" is obviously subjective. MLT parallel processing does work (to some degree) and for most things. As you noticed, there are some things where it is broken. It is actually easy to mark code sections not parallel-safe as a quick fix and stabilize things. Then, one can run with parallelism with operations automatically operating in parallel or not as indicated. However, it is not easy or enjoyable to audit and test every combination of effects. But it is an important feature along with GPU processing. If you are doing heavy image processing operations on a single thread, then the number of threads you give to the encoding module has little effect as you noticed.

When GPU processing was introduced into Kdenlive, the developer should have forced MLT image processing to be single-threaded. Parallel CPU image processing and GPU processing (inherently parallel) do not work together. That is documented. However, I do not know the factual details of this situation.

zerofossilfuel wrote:Wow. I see what you mean. I wonder of that's been fixed?

According to a recent bug report on the MLT mailing list, no. Please help identify the primary effect that is causing it. "Any kind of alpha operations" is incorrect unless you refer specifically to the "Alpha operations" effect within Kdenlive.

zerofossilfuel wrote:I also have the Sunab PPA loaded so I am running the latest and greatest 0.9.10.
...
As I watch the progress indicator, the generated output file is only 44 bytes until the progress bar gets to 97% and freezes for another period equal to the first pass. Then, and only then, does the output file start to grow in size until it's complete.

This sounds like a bad combination of MLT and Libav/FFmpeg versions. The output file should be growing in size during the entire operation regardless the number of passes, but this sounds like it is being all buffered in memory and then dumped out at the end, which is not expected or desired behavior. I do recall that Debian and perhaps others upgraded libav to a new major version in Sept. 2014 as soon as it was released, and this caused a problem in MLT's avformat module that had to fixed shortly thereafter (Sept. 22 & 23 in the source code repo).

ddennedy wrote:

zerofossilfuel wrote:I also have the Sunab PPA loaded so I am running the latest and greatest 0.9.10.
...
As I watch the progress indicator, the generated output file is only 44 bytes until the progress bar gets to 97% and freezes for another period equal to the first pass. Then, and only then, does the output file start to grow in size until it's complete.

This sounds like a bad combination of MLT and Libav/FFmpeg versions. The output file should be growing in size during the entire operation regardless the number of passes, but this sounds like it is being all buffered in memory and then dumped out at the end, which is not expected or desired behavior. I do recall that Debian and perhaps others upgraded libav to a new major version in Sept. 2014 as soon as it was released, and this caused a problem in MLT's avformat module that had to fixed shortly thereafter (Sept. 22 & 23 in the source code repo).

I'm using the Jon Severinsson ffmpeg PPA at the moment. I can try avconv/avplay later today to see if it makes any difference.

looks like sunab's svn ppa may have gotten the mlt update on the 18th? anyone try it yet? https://launchpad.net/~sunab/+archive/u ... enlive-svn