On Sat, Apr 30, 2016 at 8:23 AM Harald Albrecht <harald.albre...@gmx.net>
wrote:
> Hi,
>
> maybe someone here can shed some light on a strange performance problem
> I'm seeing...
>
> I'm using the most recent MLT from git master as the "engine" inside
> Kdenlive 16.04. When using MLT this way, it is used only single-threaded
> in my Kdenlive setup. The system I'm using is a core i7 so there are a
> lot of idle cores hanging around :)
>
> Now, I see a strange performance drop whenever in a project I have six
> or more clips in the same timeline position (the project has 8 tracks or
> so, but this doesn't matter). That is, I have six or more clips
> composited onto each other using transitions. When I start playing my
> project a few seconds before where the six or more clips are on top of
> each other, performance is okay. However, as soon as MLT enters the
> region with more than five clips, performance completely breaks down to
> one frame every several seconds. There are no filters applied to the
> clips, it is just with five clips and corresponding affine (sometimes a
>
affine is rather slow, but it does support frame-threading if you enable
that.
substract) transitions it works okay, but with an additional clip and
> transitions it completely breaks down.
>
> I've seen this behavior also a eight or nine months ago in another
> Kdenlive project with an older MLT release. Please note that in my
> situation MLT is rendering to screen. The source clips involved are two
>
> H.264 clips (1080p/30 from an HDMI recorder) and some png clips (also
> 1920x1080). The tripping point always is six clips simultaneously.
> System has 16gig, memory consumption is far from this with the project
> loaded and playing.
>
> Any idea what the reason could be? What kind of information can I supply
> to help tracking down this issue? I would exect performance to slowly
> degrade but not to completely break down by adding just another clip...
>
>
There is a cache for avformat (i.e. A/V clip) producer objects that by
default is limited to 4. This is necessary to reduce the amount of RAM,
number of open files, and number of threads (libavcodec allocates multiple
decode threads) for which there are per-process limits imposed by the
kernel. If the cache size is not high enough, then avformat producer
objects are going to be closed and re-opened for every frame during
mulitrack compositing! However, there is code in mlt_multitrack that is
supposed to increase this to #tracks + 1 whenever tracks are added. It is
possible this is being bypassed, defeated, or overridden by Kdenlive.
First, see if playing the project with melt outside of Kdenlive exhibits
the same problem.
Next, set environment variable MLT_AVFORMAT_PRODUCER_CACHE=10 to see if
that helps with either/both melt or kdenlive.
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
