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

[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 dcd7e61 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