You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I discovered a memory leak while using GSCam for a project. The problem is that, under certain circumstances, the GSCam node threat would run slower than the gstreamer pipeline and the frames will get stuck in the appsink given that nobody is pulling them at enough rate.
As I said, this is a strange combination that only occur under certain rare circumstances. In my case, this happened while running more than 2 instances of GSCam retrieving an uncompressed 4K image from capture devices (I guess the memory copy and conversion to ROS msg would take longer in this case, making the frames to get stuck in the appsink).
More specifically, the problem is seen in the following lines:
Appsink will internally use a queue to collect buffers from the streaming thread. If the application is not pulling samples fast enough, this queue will consume a lot of memory over time.
The text was updated successfully, but these errors were encountered:
clover-es
changed the title
Memory leak under certain circunstances
Memory leak under certain circumstances
May 25, 2020
Also, this can be tested in a single terminal without the use of GSCam itself, running the following commands:
Generates memory leak (nobody pulls the frames in the terminal, appsink element is not connected) gst-launch-0.10 v4l2src device=/dev/video0 ! video/x-raw-rgb,framerate=30/1 ! ffmpegcolorspace ! appsink
Does NOT generate a memory leak (nobody pulls the frames in the terminal, appsink element is not connected, BUT only one frame is stuck the buffer) gst-launch-0.10 v4l2src device=/dev/video0 ! video/x-raw-rgb,framerate=30/1 ! ffmpegcolorspace ! appsink max-buffers=1
I discovered a memory leak while using GSCam for a project. The problem is that, under certain circumstances, the GSCam node threat would run slower than the gstreamer pipeline and the frames will get stuck in the appsink given that nobody is pulling them at enough rate.
As I said, this is a strange combination that only occur under certain rare circumstances. In my case, this happened while running more than 2 instances of GSCam retrieving an uncompressed 4K image from capture devices (I guess the memory copy and conversion to ROS msg would take longer in this case, making the frames to get stuck in the appsink).
More specifically, the problem is seen in the following lines:
gscam/src/gscam.cpp
Lines 265 to 272 in 1b0b8e5
gst_app_sink_pull_sample()
(and the following code) takes longer to execute than what GStreamer is taking to generate frames in the pipeline.From GStreamer AppSink element documentation:
The text was updated successfully, but these errors were encountered: