This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Severe memory leak after last 0.9.10 kdenlive upgrade

Tags: None
(comma "," separated)
mschaap
Registered Member
Posts
6
Karma
0
vpinion:
To me mlt is a black box, but I have never tweaked its settings myself.

I could be wrong, but I base idea that melt does at leeast something on the GPU on the fact that setting de gpu settings (nvidia-settings) from "adaptive" to "maximum performance" *while* rendering makes the GPU temperature increase (this does not happen in other situations). Increasing the number of Encoder Threads in kdenlive the does absolutely nothing when I cange it from 1 to 8 (this was different in the past). I cannot provide more specific information because nvidia-smi (monitoring software) does not return valid data for my card.
User avatar
Steve Guilford
Registered Member
Posts
207
Karma
0
mschapp:

Sounds like you've encountered the Linux version of DLL Hell. I suspect you've got several versions of required libraries etc. installed.

The start-kdenlive script uses PATH & LD_LIBRARY_PATH to explicitly set the search order for needed components. If you reference the start-kdenlive script in your startup-menu, you'll be all set.
vpinon
KDE Developer
Posts
708
Karma
6
OS
Hello,

The melt executable you use is actually stored in your preferences, whatever the kdenlive version you use... except when you use the start-kdenlive script from the build script, that overrides this setting through command line option (or environment variable)! I think this was leading to the mess in your test results.

And yesterday, MLT was patched against a memory leak versus FFMpeg 2.3, so I guess this was your problem.

MLT hasn't bee rebuilt yes on PPA, so use the one from manual build until the update reaches the repo to upgrade your system melt.

Please let us know of your progress.

Vincent
User avatar
ewanchic
Registered Member
Posts
1
Karma
0
OS
I'm using Ubuntu 12.04 LTS, all up-to-date. 32GB of Ram, iCore 7. Eats and eats, and want's some Swap, but no rendering. Doesn't matter how many threads.

I tried rendering via kdenlive and via script, had a memory leak both times.

I tried upgrading to the version under 'Trusty' release, but that was causing more dependancy problems. I wasn't really able to find how to get the next, latest source for MLT, so this is what I had to do to fix it...as suggested.

First Uninstall the previous versions of kdenlive:
Code: Select all
$ apt-get remove kdenlive dvgrab frei0r-plugins kdenlive-data libepoxy0 libgavl1 libmlt++3 libmlt-data libmlt6 libmovit2 libvidstab1.0 melt


Next, modify the apt- source. Typically going to be in:
Code: Select all
/etc/apt/sources.list.d/sunab-kdenlive-release-precise.list

but, it could be under
Code: Select all
/etc/apt/sources.list


Change the location from
Code: Select all
../kdenlive-release/..
to
Code: Select all
../kdenlive-release-old/..
:
Code: Select all
deb http://ppa.launchpad.net/sunab/kdenlive-release-old/ubuntu precise main
deb-src http://ppa.launchpad.net/sunab/kdenlive-release-old/ubuntu precise main


Finally,:
Code: Select all
apt-get update
apt-get install kdenlive


Then you'll be back to kdenlive 0.9.8-1 and melt 0.9.0~3, which doesn't memory leak.
mgmalheiros
Registered Member
Posts
1
Karma
0
Same here: "melt" uses all available memory for the 0.9.10 version from the PPA.

I'm using a 12.04 LTS Ubuntu installation.

Going back to the 0.9.8 version from the PPA repository solves the issues.

Thank you all for the suggestions!
Ralf
Registered Member
Posts
1
Karma
0
I'm hitting the memory leak also for a while with the Fedora packages:

kdenlive-0.9.8-2.fc20.x86_64
mlt-0.9.2-1.fc20.x86_64

For some of the projects I was able to get away by just adding crazy amounts of swap space but in the end that's too slow so I moved the rendering script to a VM with 64GB memory where I was able to render my project for a while simply by throwing enough RAM at the bug to keep it well fed.

It appears that using slideshows with panning & zoom ("Ken Burns effect") makes the problem much worse. Also it seems that rendering for DVD (.VOB files) is making the issue much worse. My latest attempt now died the oom killer death after rendering just about 25% of the 92 minute long project; with top I was able to observe the process to grow at a rate of about 60MB/s.

Iow the bug is crippling even for well equipped machines, I'm seeing it both when rendering from kdenlive and from the script, both on a full blown desktop setup and the VM which is a minimal install on a VM with barely enough software to do the rendering.

Since everybody else here seems to be hitting the issue with 0.9.10 I'm wondering if I'm hitting a different issue?

Either way: mayday :-)

Ralf
vpinon
KDE Developer
Posts
708
Karma
6
OS
Rendering is a pure MLT job (+libav/ffmpeg), so try to switch to a different MLT version.
You may also try to use affine transition rather than pan & zoom effect, but maybe it's too late for a big project?
Last workaround trial, try to render splitting your project in 4-5 sections, in the end you can run a "ffmpeg concat:[inputfiles] outputfile"?


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot]