Closed ThomZenTury closed 1 month ago
lupin3rd
commented
1 month ago Hi @ThomZenTury ! I had reported a similar problem with loading multiple sessions (fixed in beta). The problem should not be related to the fact that the session is loaded via OSC. You should try the Vimix beta because @brunoherbelin fixed many bugs after the release of 0.8.2d. If you load sessions with the Vimix GUI do you have the same problem?
ThomZenTury
commented
1 month ago Hi @lupin3rd ! Thanks for your fast reply. I indeed had now the same issue when loading a session via the GUI and I updated my question above. I will thankfully try the beta and will answer as soon as possible (unfortunately not tonight anymore). Thanks a lot!
ThomZenTury
commented
1 month ago Good morning!
Unfortunately the issue persists also on beta branch vimix 0.8.2d-46-gbfc1354
GStreamer-CRITICAL **: 09:18:19.104: gst_poll_read_control: assertion 'set != NULL' failedIn my - very rudimentary - understanding it seems that previous sessions are not closed / do not free RAM on my system when a new session is opened. With every opened session the RAM in my system monitor fills up until ~8.5 GB (of total 16GB) and then vimix freezes with its loading circle and telling me that further sources can not be loaded.
But I am not even sure if the RAM process is how Ubuntu handles application usage and if it has anything to do with vimix.
Any more ideas/hints/questions are gratefully welcome.
Have nice day!
ThomZenTury
commented
1 month ago Additional note: I am pretty sure this is somehow related to issue #122. From the videos attached by @lupin3rd in this thread I see familiar behaviour. A big difference would be that I am working with up to three custom shaders in every session. Maybe this gives anyone new ideas.
brunoherbelin
commented
1 month ago Hi @ThomZenTury ! Thanks for your enthusiastic use of vimix, pushing it to its limits !
I will have more time next week to investigate, and can hopefully find the cause (and thus a fix). Random occurrence of crashes points towards memory leaks / RAM problem : these are nasty bugs and I cannot make promises on how fast I can find a solution..
Could you please give example of scenarios that lead to the crash (i.e. session 1 = 4 sources, then switch to session 2 = 8 sources, etc.) and some indication of their contents (video files, images, streams, clones, filters, shaders? etc.) ? This way I could try to setup a similar chain of events here.
ThomZenTury
commented
1 month ago Hi @brunoherbelin ! Thanks for joining in!
I will gladly deliver as much information as I can gather. But in general I can say that it doesn't make big of a difference (as far as I can say) in which order I change my scenes or in which frequency. With each opened scene my RAM just fills up until ~8.0 GB(on my system monitor) and then vimix says goodbye. Even if I load one and the same scene a few times until 8GB RAM use vimix will shut down (last tested with "scene03").
Following is as much information about my scenes as I could get today. Please don't hate me for the formatting. I could not find any formatting style on github for tables or similar:
scene01 (14sources, 5 clones, 3 custom shaders, 4 uniforms)
n° |source |codec |resolution |fps | div.
--------------------------------------------------------------------------------------
01 |mp4 |h264 |640x480 |25 |
02 |-> clone | | | | custom shader, 2 uniforms
03 |black pattern | |1920x1008 | |
04 |-> clone | | | | custom shader, 2 uniforms
05 | -> 2nd clone | | | | none
06 |mp4 |h264 |640x480 |30 | color correction
07 |-> clone | | | | mask, scaled
08 |mp4 |h264 |640x480 |30 |
09 |mp4 |h264 |640x480 |30 | color correction
10 |mp4 |h264 |640x480 |30 |
11 |mp4 |h264 |640x480 |30 |
12 |mp4 |h264 |640x480 |30 | color correction
13 |mp4 |h264 |640x480 |30 | mask, scaled
14 |mp4 |h264 |640x480 |30 | color correction
15 |-> clone | | | | filter: delay 1.66s
16 |black pattern | |1152x720 | |
17 |-> clone | | | | custom shader, no uniform
18 |.png | |1920x1080 |still |
19 |-> clone | | | | filter: alpha
20 |.png | |1920x1080 |still |
21 |.png | |1920x1080 |still |
scene02 (6 sources, 7 clones, 3 custom shaders, 2 uniforms)
n° |source |codec |resolution |fps | div.
--------------------------------------------------------------------------------------
01 |black pattern | |1152x720 | |
02 |-> clone | | | | custom shader, no uniform
03 |-> clone | | | | custom shader, 2 uniforms
04 | ->2nd clone | | | | filter blur opening 0.04
05 |-> clone | | | | custom shader, no uniform
06 | -> 2nd clone | | | | none
07 |mp4 |h264 |640x480 |30 |
08 |-> clone | | | | none
09 |mp4 |h264 |640x480 |30 |
10 |.png | |1920x1080 |still |
11 |-> clone | | | | filter: alpha
12 |.png | |1920x1080 |still |
13 |.png | |1920x1080 |still |
scene03 (6 sources, 9 clones, 3 custom shaders, 11 uniforms)
n° |source |codec |resolution |fps | div.
--------------------------------------------------------------------------------------
01 |black pattern | |1152x720 | |
02 |-> clone | | | | custom shader, no uniform
03 |-> clone | | | | custom shader, 4 uniforms
04 | -> 2nd clone | | | | none
05 |mp4 |h264 |640x480 |30 | scaled
06 |-> clone | | | | color correction, scaled
07 | ->2nd clone | | | | scaled
08 | ->2nd clone | | | | filter blur 0.02, scaled
09 |black pattern | |1152x720 | |
10 |-> clone | | | | custom shader, 7 uniforms
11 | -> 2nd clone | | | | filter blur opening 0.02
12 |.png | |1920x1080 |still |
13 |-> clone | | | | filter: alpha
14 |.png | |1920x1080 |still |
15 |.png | |1920x1080 |still |
scene04 (10 sources, 7 clones, 3 custom shaders, 12 uniforms)
n° |source |codec |resolution |fps | div.
--------------------------------------------------------------------------------------
01 |black pattern | |1152x720 | |
02 |-> clone | | | | custom shader, 7 uniforms
03 | -> 2nd clone | | | | blur opening 0.04
04 |-> clone | | | | custom shader, 1 uniform
05 | -> 2nd clone | | | | color correction
06 | -> 3rd clone| | | | color correction
07 |-> clone | | | | custom shader, 4 uniforms
08 |mp4 |h264 |640x480 |30 | scaled
09 |mp4 |h264 |640x480 |30 | scaled
10 |mp4 |h264 |640x480 |30 | scaled
11 |mp4 |h264 |640x480 |30 | scaled
12 |mp4 |h264 |640x480 |30 | scaled
13 |mp4 |h264 |640x480 |30 | scaled
14 |.png | |1920x1080 |still |
15 |-> clone | | | | filter: alpha
16 |.png | |1920x1080 |still |
17 |.png | |1920x1080 |still |
scene05 (7 sources, 12 clones, 5 custom shaders, 10 uniforms)
n° |source |codec |resolution |fps | div.
--------------------------------------------------------------------------------------
01 |black pattern | |1152x720 | |
02 |-> clone | | | | custom shader, 1 uniform
03 | -> 2nd clone | | | | color correction
04 | -> 3rd clone| | | | color correction
05 |-> clone | | | | custom shader, 3 uniforms
06 |-> clone | | | | custom shader, 2 uniforms
07 |-> clone | | | | custom shader, 4 uniforms
08 |-> clone | | | | custom shader, no uniform
09 | -> 2nd clone | | | | color correction
10 |mp4 |h264 |640x480 |30 | scaled
11 |mp4 |h264 |640x480 |30 | scaled
12 |-> clone | | | | scaled
13 |-> clone | | | | scaled
14 |mp4 |h264 |640x480 |25 | scaled
15 |-> clone | | | | color, correction, scaled
10 |.png | |1920x1080 |still |
11 |-> clone | | | | filter: alpha
12 |.png | |1920x1080 |still |
13 |.png | |1920x1080 |still |
scene06 (5 sources, 4 clones, 1 custom shader, no uniform)
n° |source |codec |resolution |fps | div.
--------------------------------------------------------------------------------------
01 |black pattern | |1152x720 | |
02 |-> clone | | | | custom shader, no uniform
03 | -> 2nd clone | | | | filter edge freichen 0.76
04 |mp4 |h264 |640x480 |30 | scaled
05 |-> clone | | | | color correction, scaled
06 |.png | |1920x1080 |still |
07 |-> clone | | | | filter: alpha
08 |.png | |1920x1080 |still |
09 |.png | |1920x1080 |still |
10 | | | | |I really hope I can help with this. For the gig next week I will find a solution. Although I really hope that I can use vimix soon with its full potential. As I already wrote - shaders with external controllable uniforms is like a dream coming true for me!
Btw. I am pretty sure I will open another issue soon about constant flow of incoming OSC data crashing vimix. So, please don't be bothered by the amount of my threads these days.
Have a nice day!
P.S.: If you are interested in the project files please let me know. They are not big of a secret.
brunoherbelin
commented
1 month ago Thanks! I am working on it. As expected, memory management issues take long to fix... :disappointed:
The issue is that, indeed, closing a media does not releases all the RAM allocated. It is a gstreamer problem, which uses its own allocators and referencing mechanisms (i.e. I cannot call 'free' on pointers). I thought I had it correctly implemented but there is apparently something wrong...
brunoherbelin
commented
1 month ago Please try to build the Beta version, e.g. with a custom flatpak https://github.com/brunoherbelin/vimix/tree/master/flatpak
I did some serous stress-tests (loading 4 videos of 4K resolution over 20 times in a row) and the OS seems to eventually limit the RAM usage of vimix. NB: it is normal that, if there is enough RAM available, Linux gives a lot of RAM to processes when they start asking for memory; the RAM consumption of the process grows at first. But if there starts to be pressure on memory consumption, then the system does not allocate more and manages the RAM in a more strict way. However indeed, the program should be able to reuse the RAM it was allocated, and this seems to be better for vimix now... :crossed_fingers:
brunoherbelin
commented
1 month ago Update: the new snap release compiled with this fix : https://snapcraft.io/vimix
ThomZenTury
commented
1 month ago Wohoo!
Compiling the beta 0.8.2d-54-gd22e239 and forcefully testing just wants to make me say "Thank you so much!". 10 minutes of just switching and loading scenes does not end any more in crashes or hickups. Just a stable RAM use somewhere between 4GB to 6GB (system monitor) and 2GB to 4GB on the Vimix metrics.
I cannot thank you enough for your efforts to make Vimix constantly more awesome than it already is.
If there is anything I could deliver in return please let me know.
Have a great weekend!
brunoherbelin
commented
1 month ago Hi again ! I made some further improvements, and memory is even more drastically managed now (in Beta for now, same procedure). It uses approx 400MB less RAM for the base program, and a ~20% less use for loading videos. Would be curious to have your feedback after testing further...
Thanks for your enthusiastic feedback ! I like the geeking and seeing people happy with creative use of computers is good enough ! If you want to help, tutorials of vimix (the basics or how you use it) would be great to share !
ThomZenTury
commented
1 month ago Holy code! Excited about your post I recompiled and ... what can I say?! I maybe expected something but this looks like wizardry! None of my sessions consume more than ~2GB RAM now, no matter what. This is not an improvement this is being confident with my laptop/setup/hardware again.
I was thinking about making tutorials again for a long time now and I think you just gave me the last push. Vimix and your work on it is certainly worth it. I will let you know as soon as my schedule will allow me to.
Thank you so much!
Hi there!
I would finally change to "vimix" next week on a gig simply because it is an amazing software. So, again, thank you for creating.
UPDATE: It also happened for the first time now when I opened a new session from within vimix via "Playlist". Original: Unfortunately I encounter random crashes when changing sessions with the OSC command "/vimix/session/open". In general it works flawlessly, but after some minutes it crashes with either one of these errors:
or
This is my current setup:
System: Ubuntu Studio / Kubuntu 22.04.04 / 6.2.0-1017-lowlatency CPU: Intel i7-10750H (12) @ 5.000GHz GPU: NVIDIA GeForce RTX 2060 Mobile
Software: Vimix 0.8.2d-28-g94fbe58 Chataigne 1.9.19
Some Midi Controllers attached to the PC.
I am using some custom shaders that I control via OSC commands, i.e. their uniforms. I love this feature! Mainly that is the reason why I want to go with vimix in future.
The shaders seem to have nothing to do with it, as the errors occur very randomly. It is not always the same scene that I am switching to, it's also no specific runtime (can happen after 30 seconds or after ten minutes), it is also not abut the times i switch to a new scene.
What I notice also is a permanent filling RAM with each opened session. At about 9GB system monitor / 4.5 GB vimix monitor the app shuts down.
I am sorry for not being able to deliver more hints here.
It would be great if you could maybe look into that issue or give me some advice what I could do for further debugging.
Have a nice day!