SUMMARY Kdenlive eats up all memory when rendering, resulting in a frozen machine and corrupted output file. This happens regardless of distro and Kdenlive version I use. Tried on Kubuntu 23.04, 23.10, 24.04, and on latest KDE Neon. STEPS TO REPRODUCE 1. Get some 4K footage; 2. Make edits. The more, the better; 3. (not necessary, but that's my workflow) Add a corresponding LOG to Rec. 709 LUT onto every roll; 4. Make the video about half an hour long; 5. Try rendering the entire thing or a significant chunk of it. Output codec doesn't matter, just make sure you're not scaling output down. OBSERVED RESULT All available memory gets eaten up, computer freezes at some point (when there's no memory available anymore), the output file is corrupted. EXPECTED RESULT Memory consumption remains sane throughout the entire rendering process, computer doesn't hang, output file isn't corrupted. SOFTWARE/OS VERSIONS Linux/KDE Plasma: any KDE Plasma Version: any KDE Frameworks Version: any Qt Version: any ADDITIONAL INFORMATION Footage I use is in H.264 24 FPS 100 Mbit/s and H.265 25 FPS 250 Mbit/s. The issue has something to do with the resulting video length and number of clips alternating on the timeline. Changing output codec does only introduce a marginal difference. Rendering video in small chunks and gluing them up using ffmpeg works, but it's very clumsy and should be totally unnecessary.
The problem occurs also with - Software-based H.264 and H.265 rendering - Hardware-based H.264 and H.265 rendering Both with parallel and single-thread processing. The source files are GoPro videos in H.265 format, 5.3k, 30fps. Output format is 4k, 30fps.
Problem observed on Ubuntu 24.04, Snap version 25.03.70, but latest AppImage version fails as well.
I have switched back to Kdenlive 24.08.3 (AppImage). Same problem occurs. It worked with the old version last year, so I suspect that the updated MLT is causing the problem. Unfortunately, switching back to an older MLT version is far more difficult.
MELT version is 7.22.0-1build6 (installed as DEB package via Synaptic)
Link to download self-contained archive: https://www.dropbox.com/scl/fi/zyenxjsrxgtecobnip72q/kdenlive-memoryleak-debug.zip?rlkey=3pantm0e7810e0yspmbhvislx&st=7eipuktb&dl=0
My hardware specs: CPU: AMD Ryzen 5600G RAM: DDR4 3600 MHz 2×16 GiB dual channel (1.5 GiB dedicated to integrated GPU) GPU: AMD Vega integrated Motherboard: ASUS Prime B550M-A SSD: Gigabyte GP-GSM2NE3256GNTD (256 GB) HDD: Seagate Barracuda ST2000DM006-2DM1
The memory usage increases in steps, while staying constant for a few minutes. I believe that this is because the whole clip gets loaded into memory for decoding, filtering and encoding, and when progressing to the next clip, the previous one is not discarded. The steps in memory usage also coincide nicely with the file sizes of the imported clips.
I have had a long conversation with Grok AI about the problem: https://x.com/i/grok/share/Hi5LxWJWbcPSno45RTDthMkDM
(In reply to Gerhard from comment #5) > Link to download self-contained archive: > > https://www.dropbox.com/scl/fi/zyenxjsrxgtecobnip72q/kdenlive-memoryleak- > debug.zip?rlkey=3pantm0e7810e0yspmbhvislx&st=7eipuktb&dl=0 I cannot reproduce the crash with the provided project but the memory reached about 12gb out of 16gb. When having a browser open while rendering the swap reached its full capacity of 16gb.
Git commit 6d0511bf4fcc69220e18be784b9b8bb25ec78535 by Jean-Baptiste Mardelle. Committed on 20/03/2025 at 08:28. Pushed by mardelle into branch 'release/25.04'. Fix autoclose attribute not properly set on playlists on rendering, causing huge memory usage M +17 -1 src/doc/kdenlivedoc.cpp M +3 -3 src/render/renderrequest.cpp https://invent.kde.org/multimedia/kdenlive/-/commit/6d0511bf4fcc69220e18be784b9b8bb25ec78535
Thanks a lot for your detailed report and investigation . Attaching the project archive helped a lot. I am glad to say that I fixed the problem. In fact, the "autoclose" attribute was not correctly set on MLT playlists, causing it to not close the clips once they were not needed anymore. Now the rendering process stays around 10GB and doesn't grow indefinitely. I also upgraded our memory checker that was not very effective, so you now should get a proper warning if memory goes below 10% of the available RAM while rendering. Would be great if you could test the daily build AppImage that contains my last changes to confirm my fix: https://cdn.kde.org/ci-builds/multimedia/kdenlive/master/linux/
Huge fix. I confirm that it now stays at 7Gb of memory consumption and the is not used swap as far as I can tell. Thanks.
Created attachment 179601 [details] htop of memory usage
Created attachment 179618 [details] Memory consumption after the fix (near peak) Memory consumption reached almost 18 GiB just before the end of the rendering process. Sort of fixed, but not quite, as I would still be unable to render this project on my laptop which only has 16 GiB of RAM. Project length is 56 minutes 52 seconds, source files are H.265 250 Mbit/s, effects used are LUT, Transform (not on all clips), and Technicolor.
Huge improvement. I have checked both software H.265 and NVENC H.265 options with aggressive accelerations (many threads, parallel processing enabled) and the memory usage stayed constant while rendering from H.265 to H.265. There was a slight increase (but only once) when it started rendering 45 megapixel photos with pan and zoom effect but it then stayed at this level so it may just be due to the large amount of data from the images. Note that I managed to render my full project with the old version, but with very slow settings, resulting in an afully slow rate of 2fps. And it was just short of memory exhaustion. With the corrected version and software encoding, I get 4fps and with NVENC, it's 6fps for H.265 round-trip. Encoding rate increases to ~25fps when rendering photos with pan and zoom effect to H.265. Many thanks for the fast correction!!!
(In reply to Alex Polevoi from comment #14) > Created attachment 179618 [details] > Memory consumption after the fix (near peak) > > Memory consumption reached almost 18 GiB just before the end of the > rendering process. Sort of fixed, but not quite, as I would still be unable > to render this project on my laptop which only has 16 GiB of RAM. Project > length is 56 minutes 52 seconds, source files are H.265 250 Mbit/s, effects > used are LUT, Transform (not on all clips), and Technicolor. > Rendering video in small chunks and gluing them up using ffmpeg works, but it's very clumsy and should be totally unnecessary. I always use guide multi-export, just in case I want to change pieces or if the render crashes or anything, it's easy to combine the chunks with Avidemux or ffmpeg Would be cool if Kdenlive could automatically do the render in pieces and combine the files at the end
(In reply to die4ever2005 from comment #16) > Would be cool if Kdenlive could automatically do the render in pieces and > combine the files at the end Please create a new report for this and make it a **Wish List** item. That way your suggestion / feature request doesn't get lost or buried in this thread (which is considered closed and will be flagged as such anytime soon).