brunoherbelin / vimix

Live Video Mixer
GNU General Public License v3.0
260 stars 25 forks source link

Memory usage increases #28

Closed OlegoroV closed 3 years ago

OlegoroV commented 3 years ago

Memory usage gets higher on every new video source opening (even before I press Create button), reloading session, opening new session, fading video in (although memory was already eaten a little bit by creating this source). Fading video out doesn't decreases memory usage.

brunoherbelin commented 3 years ago

Thanks for pointing this out. There were indeed new memory leaks since the last time I checked!

But a thourough memory check and cleanup should now have cleared the issue.

Below an example with Valgrind memory consumption test during loading & closing sessions mutiple times. Screenshot-20210404181539-1892x737 Detailed legend: 4 times cycle of loading a small session and closing it, then load a larger session 1 time, close it, and load again the small session 1 time before terminate the program. You can note the bouncing up-down every time the session is closed: this is because vimix first creates the new session before doing the transition with the closing session (at one point, two sessions are therefore in memory)

Please note however that (mostly under Linux), memory management is not strict and the system keeps a reserve of memory for future use: the idea is that an application that once needed a certain amount of space will very probably need it again later. Thus the return to baseline is not a return to zero.

OlegoroV commented 3 years ago

Just tested build 422 from snap I don't know how to make visual graphic, so only digits:

At program start - 140 MB in memory First session loaded (with video in center) - 660 MB Second session loaded (with the same video in center) - 1.11 GB Again first session - 1.45 GB Again second session - 1.72 GB And so on: 1.93 GB, 2.09 GB, 2.23 GB, 2.39 GB, 2.52 GB

Manually compiled version results: 143 MB at start Then 606 MB, 926 MB, 1.12 GB, 1.28GB, 1.41 GB, 1.50 GB, 1.60 GB, 1.67 GB

Much better!!!

OlegoroV commented 3 years ago

Tried to use valgrind - Vimix freezes at mixing between sessions.

brunoherbelin commented 3 years ago

memoryusagevimix_reloadmanytimes

Memory consumption by vimix is confirmed as stabilized ! The amount of RAM allocated by the system might increase as the program requires resources, but the allocated memory stabilizes after a while, showing that there is no memory leak (see above : each peak is a reload of the same session).

Latest changes are available on git already, soon in the release.

brunoherbelin commented 3 years ago

PS: if you want to plot by yourself, open the toolbox (CTRL + T) and choose stats/Record

OlegoroV commented 3 years ago

My test is not so good.

First test. Just reopening same session with Ctrl+Shift+O. VimixMemTest_01

Second test. Reopening same session with transition. (Don't look at artifact near center of graph. I accidentally added session to the previous one)

VimixMemTest_02

Third test. Reopening two similar sessions alternately with transition.

VimixMemTest_03

brunoherbelin commented 3 years ago

Hi This looks like normal behavior to me: it stabilizes after a while. Just to confirm: the 2.5GB RAM allocated are still available in RAM on your machine? How many % does that represent over the total available? The system might just consider it is faster to give more RAM than to spend time re-ordering memory and cleaning it up...

If you want to change the memory management of your system for a process, you can try numactl: https://linux.die.net/man/8/numactl Let me know if this helps

OlegoroV commented 3 years ago

I've got 16GB of RAM. OK, let it be normal behavior. One more note. Several latest builds spend more time to load next session before transition.

brunoherbelin commented 3 years ago

vimix is under scrutiny with you :) ! Good that you noticed that the loading changed.

yes indeed as part of the effort to minimize memory increase, I now limit vimix to sequentially open media files (videos or images), with at most two files in parallel. Loading is therefore slower.

Before, when loading a session, vimix would parse the XML mix file and immediately start opening all the files in parallel. If there are many files to load, this creates in parallel as many file loaders, which all immediately ask for their own memory and CPU. This caused a rush for resources which was hard to control.

If this is a problem let me know. It could also be decided to limit to 3 instead of 2, if loading is really slow; It's really a compromise to find. (but for sure I would like to avoid yet another user preference that most people would not understand.)

OlegoroV commented 3 years ago

Is it possible to load firstly only sources that are inside of mixing circle? And after that let user to start transition. And only after continue loading all other sources? And yet more observation: while transition mode is running, FPS is only 30.