Memory leak when Kdenlive project contains clip with changed speed and FX

[Arpatle]

ClipSpeed100_RAMstable_MLTscript.txt ClipSpeed50_RAMleak_MLTscript.txt When I render a Kdenlive project which contains a video at a different speed than 100%, AND at least one effect, the RAM usage of the 'melt-7' process is ever increasing, until my system freezes.

If I remove all FX on that clip while keeping the speed change (at e.g. 50%), RAM usage remains stable at about 500 MB on my system. If I keep FX applied on a clip, but change the speed to 100%, RAM usage also remains stable.

Changing the number of threads doesn't make a difference.

Please find attached MLT script files, one containing a video on 50% speed, the other at 100% (I needed to change the .mlt extension to .txt)

My system specs:

• Ubuntu 22.04.3, 4 GB RAM, Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz, Intel HD Graphics 620
• MLT 7.20.0, Kdenlive version 23.08.2

[Arpatle]

Update: I could reproduce this issue on my Windows 10 partition of the same laptop (same specs as above) and on another Linux Mint 21.2 desktop (Intel Pentium 4, 2 GB RAM).

I've been testing around with different files and conversions of them, and I found out that this issue does not occur on all kinds of input files. It seems like the problem only occurs if the source video has interlaced scanning. FYI: my source material is coming from a Sony camera, using 50i frame rate.

Please see attached test comparison table I just created. I copied the data from the 'Clip Properties' tab in Kdenlive, so these are the properties of different source files.

To summarize, a memory leak during rendering happens when:

• Changing the clip's speed (to e.g. 50%)
• Adding effects to it (e.g. Brightness and Contrast)
• As I assume now (I can't confirm though) the source material has interlaced scanning

I'd be happy to do further testing.

[ddennedy]

I reproduced it, which is why I tagged it as confirmed, with an interlaced AVCHD (MTS) test clip. I found the problem is when using our YADIF deinterlacer. I was also able to reproduce it using a command line like: melt timewarp:0.5:JVC.mov -attach frei0r.brightness -consumer sdl2 progressive=1 deinterlacer=yadif

If I change the deinterlacer to "onefield" or "linearblend" the problem goes away. I also found that it is not limited to the timewarp producer (speed change). This also reproduces it here: melt JVC.mov -attach frei0r.brightness -consumer sdl2 progressive=1 deinterlacer=yadif

I have not found the root cause, however.

[Arpatle]

Thanks a million! I've added "deinterlacer=onefield" as an extra parameter in my Kdenlive render profile. I can confirm that the memory leak is gone now and the rendered video looks good. Also, I noticed the rendering process took way less time.

BTW, as I'm a newbie here, should I close this thread?

[ddennedy]

No don’t close as this is a bug that needs fixing.

[ddennedy]

@bmatherly please help me with this. I found this is a regression in your commit dcd7e617a via git bisect. I found it reproduces with any filter that needs rgb(a) such as box_blur too - not just frei0r. It also reproduces in some ways in Shotcut. This is a blocking bug for the next release of both MLT and Shotcut as it is easily triggered. Here is another minimal command line to reproduce (and monitor RSS memory): melt interlaced.mov -attach box_blur -consumer null progressive=1 deinterlacer=yadif

This does not reproduce it even though logging tells me it is exercising image conversion and deinterlace in a similar manner showing the problem in the avformat producer: melt color set.progressive=0 -attach box_blur -consumer null progressive=1 deinterlacer=yadif