Registered Member
|
KDEnlive version: 18.08.3
OS: Linux This has never happened before, but because KDEnlive for Windows always had issues with rendering (codecpar headache) and often did not render many effects, I have used KDEnlive on Linux for quite a while, which works much better. I had to convert the paths in the old project file to the Linux paths, and the project loads perfectly fine. But when trying to render it, it starts rendering, but the “melt” process eats more and more RAM. About 4 GB of RAM after having rendered one minute of the target video, and always increasing. It never happened before. How can I fix it? If there is anything you need me to try, or any questions, please let me know. |
KDE Developer
|
Latest version is 19.08.2, you should try downloading that AppImage version.
There has been such problem in MLT several years ago if I remember well, that are not present anymore (we have been rendering huge project with melt 6.16 and latest git last months & weeks). Are you using special footage (huge resolution pictures); which effects ? |
Registered Member
|
I will try that last version. No, that video is just 480p@30fps (I have worked with 2160p@60fps and 1080p@60fps without issues on kdv 18.08.3. No issues. Slow but flawless rendering.) Maybe it has something to do with the Windows-to-Linux path conversion (the project was originally created on Windows KDenlive 18.04.4, as far as I can remember, and the paths were replaced using a text editor and regular expressions applied to the project file), but it shows up perfectly fine in the editor itself. Only the rendering process experiences this issue. |
Registered Member
|
It works perfectly with it. Melt only needed 700 MB RAM and rednered flawlessly. But I miss the track height shortcuts (“smaller tracks”, “bigger tracks”) in the new version. Why have they been removed? |
KDE Developer
|
Ah yes I remember such a bug: when clips resource are not found they are switched to a qtext producer with "INVALID" text, but if the resource tag remains filled and the file is found, then qtext tries to display as text the content of the file (probably huge binary data), and this causes the memory runaway. This has been fixed since 18.08.
In any case you should search for "qtext" in your project and replace with "avformat". |
Registered users: Baidu [Spider], Bing [Bot], Google [Bot]