[Kdenlive-devel] Pop quiz to finish off KDE-Digest story

[Dan Dennedy]

On Wed, Nov 5, 2008 at 1:03 PM, Mads Bondo Dydensborg
<mads at dydensborg.dk> wrote:
> onsdag 05 November 2008 skrev jb:
>> On Wednesday 05 November 2008 20.40:16 Bugs Bane wrote:
>>
>> > 1. I think I remember reading that Kdenlive takes advantage of
>> > multi-core CPU's now. Is this accurate?
>> Kdenlive itself is not using threads. But MLT now supports multi-threading
>> (using FFmpeg threads)... that's all I can say about that.
>
> It is though, isn't? I think of e.g. the kthumb audiothumbproducer, which I,
> incidently, suspect of creating _some_ issues when pushed a bit...
>
> For rendering, here is a snippet from Dan Dennedy, Feb 13. 2008:
>
> "Also, you should no longer supply a real_time option with consumer
> avformat because it now defaults to an improved multi-threaded
> architecture that works even with non-threaded codecs! This just
> separates the encoding from the decoding and processing. So, it will
> only max out 2 processors. If you have more than 2 processors, then
> you can enable the multi-threaded codecs using the threads property or
> MLT_AVFORMAT_THREADS environment variable."
>
> I read this to say, that by default, encoding and decoding always runs on
> seperate threads, which means that kdenlive rendering should always be able
> to max out at least two processers/cores. Additionally, should you have more

This is slightly misleading about maxing out processors because it
assumes some even
division of work load, and that is not what goes on here. For example,
decode is often lighter than encode. However, any audio and image
processing takes place in the decode thread and that could outweigh
the encode thread. In addition to these two threads, there is a third
"controller" thread.

> than two cores, you can control the number of threads that ffmpeg uses as Dan
> states.
>
> (Let me mention in passing, that kdenlive_start sets MLT_AVFORMAT_THREADS to
> the number of cores in your system :-)

You might want to reduce this by -1 or /2. This gives the same number
to both decode and encode (not many codecs actually support it).
Setting this also creates a non-worker/controller thread somewhere in
libavcodec. Unfortunately, there is a scalability problem. Since
kdenlive is non-sequential, it can not take advantage of "autoclose"
of producers in MLT. Therefore, a kdenlive project leaves a producer
open once it has been accessed. An open, used producer contains
$MLT_AVFORMAT_THREADS+1. Now that kdenlive has been re-architected to
not share producers to workaround audio distortion in mixing, you have
to think in terms of "shots" or "snippets." As a result, you can
easily exhaust the number of threads per process where some default
configurations are as low as 512. Given a quad core system, then you
might only be able to put 102 shots ((4+1)*100=510) on the timeline.

-- 
+-DRD-+