Memory leak

[AGPX]

Describe the bug After encoding a video with ffmpeg.run(), the memory allocation increases but will never be released. Even with ffmpeg.exit() nothing changes (I stored the .png files in the virtual FS and then I've removed them after the video encoding was done).

To Reproduce Encode a video using images stored in virtual file system. I've used the command:

ffmpeg.run('-framerate', '60', '-i', 'input%d.png', '-crf', '18', '-c:v', 'libx264', '-pix_fmt', 'yuv420p', 'output.mp4');

You can watch the memory grow in the Task Manager over and over, never going back significantly. I've also tried running the garbage collector from Chrome, but it doesn't change anything.

Expected behavior The memory must be released at the end of the encoding.

Desktop (please complete the following information):

• OS: Windows 10 Pro
• Browser: Chrome
• Version: 113

[benz2012]

I'm not saying that you're wrong, but this doesn't necessarily describe a memory leak. Chrome could be allocating that memory from the computer and holding on to it in case it needs it again.

I do however see the same behavior using Activity Monitor on OSX with Chrome. Closing the tab seems to free the memory.

[AGPX]

Closing the tab kills the process and releases the memory. In my case I see the memory grow from 180Mb (before the encoding starts) to over 1.5Gb and it is never freed afterwards, not even by manually running the garbage collector (which is possible in Chrome). I fixed it by creating a child process which finally exits with process.exit(0). A solution that works, but I don't like it.

[benz2012]

I wasn't aware you could create child processes from browser Javascript. Are you talking about NodeJS?

[AGPX]

Yes, it's an Electron application.

[benz2012]

I know this doesn't solve the issue, but another approach for your use case could be including a pre-compiled ffmpeg binary per-OS and using the fully-fledged ffmpeg instead of the WASM one.

This thread has a number of ideas regarding that idea

[AGPX]

Thanks for this link, but I prefer to avoid stressing the SSD as much as possible and therefore I prefer to take advantage of the virtual file system, but your link is interesting, maybe it's better to also support an external execution of ffmpeg when the WASM one is not able to handle an animation, maybe because it's too long or if it takes too much time to encode (I don't know how much WASM is slower than the executable version, I was totally unable to understand what to modify in the sources to recompile WASM with advanced instruction set like AVX).

[baoziv587]

Same issue when I called ffmpeg.terminate(). Then i need to use ffmpeg again, so have to call ffmpeg.load , mem goes up after you call ffmpeg.load again and againd . So I guess some mem did not release when the user call terminate