Sunabs version of 0.9.10 leads to severe memory leak when rendering. It appears that mlt consumes all memory within a minute after the start of rendering.

System: Ubuntu 12.04 LTS (with new HWE stack), Lenovo W520 with 16 GB RAM and Core i7.

A project that was rendered correctly in 0.9.8 (yesterday) exhibits the same problems in 0.9.10 today.

I tried 1-pass vs 2-pass rendering and reducing the number of threads to 1. The problem remains.

It seems to be impossible to revert to Sunabs 0.9.8 with synaptic.

Any ideas what might cause this problem?


Added: I'm rendering with the H.264 codec (720p 30fps 400kbs video 128 kbs audio, video of lecture with slides).

Thanks!
Marcel

My render on 0.9.10 consumes 83% of memory 3.2G of 3.9G of RAM. But my system is still responsive.

Do you get 100% RAM usage and system degradation ?

If you generate a script from the render dialog and run it with kdenlive closed, is the problem still here?
if yes, the problem is in MLT, if no it is in Kdenlive, so it helps to look for the problem!

Hi,

Please test following vpinon's advice. And if reverting to kdenlive 0.9.8 if absolutely needed you can do it by :
- deleting all packages (kdenlive, mlt, ...) from the kdenlive-release ppa (manually or with ppa-purge)
- disabling ppa:sunab/kdenlive-release
- installing kdenlive from ppa:sunab/kdenlive-release-old

It contains kdenlive release -1 for emergency situations.

Thanks for the suggestions!

I can confirm that the issue goes away when using a script (should have tried that right away...). Within kdenlive it simply uses ALL 16G RAM, with everything else being swapped, so the system becomes unresponsive. The script uses only 310 MB.....

The script is a workable solution for me - I'm generating videos of my lectures 3x per week. Let me know if you would want me to run some tests (different codecs, etc). I tried compiling kdenlive from source yesterday, but the build-script failed on an outdated version of yasm (Ubuntu 12.04).

And: thanks for working on kdenlive. I find it an excellent piece of software!

To help finding the problem, can you check if memory is still eaten if you disable timeline thumbnails? (if you had it enabled, disable it and restart Kdenlive)
Thanks!

I got exactly the same problem. The physical memory (12 GB) fills in about 30 seconds and then it starts to eat the available swap memory. System responsiveness goes down and eventually stalls.

This is true for both the rendering from within kdenlive as well as running the script from a command shell (kdenlive not started).

I run several tests and for some of them the script aborted when the swap memory was all eaten up. The last test I run after a system reboot however did not abort, the system stalled and I had to pull the plug to reboot.

I am running Kubuntu 12.04 LTS.

Regards,

Michel

vpinion: the problem remains the same with video and audio thumbnails disabled, and kdenlive restarted.

script rendering works like a charm for me.

To clarify: top says it is *melt* that eats all the RAM when rendering IN kdenlive, not the kdenlive process itself. I tried a few other codecs (mpg2 and webm). Same problem.

My programming/scripting skills are "reasonable", so let me know if you'd like me to try something else.

mschaap wrote:vpinion: the problem remains the same with video and audio thumbnails disabled, and kdenlive restarted.

script rendering works like a charm for me.

To clarify: top says it is *melt* that eats all the RAM when rendering IN kdenlive, not the kdenlive process itself. I tried a few other codecs (mpg2 and webm). Same problem.

My programming/scripting skills are "reasonable", so let me know if you'd like me to try something else.

mschaap: Is it possible for you to post up your source clips and project file? We'll need to reproduce this within a configured development environment to track all of this down. All I need are the source clips and your project file.

I uploaded a "dummy" project+files (about 50 MB) to:

https://www.dropbox.com/sh/ckmw2kgn2p3i4jx/AACJuWYH8koplYspBEdwZP0ha?dl=0

This project exhibits the same issue, but to keep things small it is simplified relative to my other projects (normally there is a compositie of two video streams). What you see in this project is an title slide and a screen-capture (done with ffmpeg with H.264 codec to mkv). There is no audio here.

My system setup (Ubuntu 12.04 with new HWE) is fairly standard. I do have a custom ffmpeg, but that one lives in my home directory and is not used by kdenlive (I'm using the default kdenlive system settings).

Not sure this is important: melt appears to use my GPU when rendering (I have a Nvidia Quadro 2000M).

Thanks...I'll have a look tomorrow....

Your project rendered just fine for me. I built Kdenlive using the build script a few days ago. I'm on Ubuntu 14.04 LTS.

The first thing I'd do is build a fresh copy of Kdenlive using Dan's script. You'll need to try to minimize the differences between your system and mine. See if you can get your yasm version upgraded. Perhaps that would be enough to get the build script to run on your system.

Hello,

I just opened your project to start an export... Memory not diverging on Debian Jessie (official packages or manual builds) nor Kubuntu 14.04 (sunab's PPA; sorry no 12.04 chroot).

I sometimes see MLT very slow and memory hungry with Kdenlive title clips, especially with long scrolls (creating internally large RGBA QImage?), but as the plans were to switch to webvfx I never worked on the issue (in MLT, but Kdenlive's part).
Well, it doesn't seem to be the case here, and nothing changed fo long on this part. Just a kind of warning : if you want to do that rather use a SVG editor and use affine!

melt appears to use my GPU when rendering

How do you have this idea? I don't know where to find this option, except maybe a MLT environment variable (or export profile parameter)?
VDPAU usage in melt has always been marked as experimental, doesn't bring much improvements as filters & encoders are not (yet) on GPU.
So you shouldn't use it, even for testing as I don't believe it is under focus at the moment (the same for Kdenlive's OpenGL display option)!

Ok I compiled kdenlive from source (20141011), which I will call "new". No memory leak there when starting from commandline.

But the situation is a bit more confusing...
* old version (sunabs ppa, 0.9.10) started from gnome-classic (session fallback): memory leak (as reported).
* old version with just /usr/bin/melt replaced with the melt of the newly compiled verion: NO memory leak.
So, clearly the problem is/was in melt, right? But no:
* starting the *old* version /usr/bin/kdenlive from the *commandline* (just as the new version): NO memory leak (!!)
* replacing kdenlive in the gnome menu with the *new version* of kdenlive and all /usr/bin defaults (resources): memory leak
* same + replacing usr/bin/melt with the melt of the newly compiled version: no memory leak

So it appears to me that a different environment gets passed on to melt when running kdenlive from the commandline (no problems) than when running kdenlive from gnome-classic. The new and old version both have problems when using /usr/bin/melt (which is from sunabs ppa).

In any case the issue appears to be resolved in the new code (since the old version works with the new melt...). So, I think, if sunabs ppa would be updated with the most recent code the problem would go away.