Hello,
Those many process seems normal, it is a way HTOP displays some forks I thinks ? Original deepstream-app does the same with HTOP and 4 rtsp live stream.
In fact, the problems seem to be related to PTS, not those many process or filesystem.
In fact each time the RAM suddenly grows up, the file were not splited well, next file was smaller and the next one was more than what I told splitmuxsink to split?
-rw-rw-r-- 1 domo domo 336650167 avril 1 11:04 camia-Apr01-2020-10-49-52-099.mp4
-rw-rw-r-- 1 domo domo 336019592 avril 1 11:19 camia-Apr01-2020-11-04-54-100.mp4
-rw-rw-r-- 1 domo domo 288521415 avril 1 12:22 camia-Apr01-2020-11-19-57-101.mp4
-rw-rw-r-- 1 domo domo 1114375048 avril 1 12:22 camia-Apr01-2020-12-22-41-102.mp4*
So I focused on something related to timestamps:
Since the beginning Deepstream-app was not working with one of my cameras, it was throwing:
Debug info: gstqtmux.c(4561): gst_qt_mux_add_buffer (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin2/GstSplitMuxSink:sink_sub_bin_sink2/GstMP4Mux:muxer:
Buffer has no PTS.
Quitting
To make it works, I used live-source=1 and were obliged to use in my code :
“gst_base_parse_set_pts_interpolation” to interpolate PTS, and it was ok, no error except for sudden memory leak after 10 or sometimes 17 hours.
So I decided yesterday to take off gst_base_parse_set_pts_interpolation function and set live-source=0 (whereas I am working with live sources) so in this case the muxer calculates timestamps based on the frame rate of the source which first negotiates capabilities with the muxer.
And now all is ok? the DVR had runs for more than 24 hours without any problem and the RAM is stable … I will continue to make more tests