Release RAM, when close or reload stream

Thu Apr 18 11:42:17 UTC 2024

Regarding the memory increase, it definitelly should not keep increasing
constantly. Consider building your project with address sanitizer
https://releases.llvm.org/11.0.0/tools/clang/docs/AddressSanitizer.html
gcc compiler supports the same compilation flags. The output will be also
improved if you build gstreamer and glib with sanitizer.
If I recall correctly this can be done by

ASAN_OPTIONS=detect_leaks=1  meson build -Dintrospection=disabled
-Db_sanitize=address
ASAN_OPTIONS=detect_leaks=1 ninja -C build

But remember to set environment variable G_SLICE=always-malloc when running
with glib version lesser then 2.76, otherwise memory tracking tools won't
work.

>  I am also interested in the question of changing the location in
rtspsrc, what is the most correct tactic?

I'm not sure if setting rtspsrc to NULL is enough, I remember one project
was setting the whole pipeline's state to NULL before changing the url of
the rtspsrc. But the reasons behind that is that the new link was likely
carrying a different video format, so that project preferred to rebuild the
whole pipeline anyway.
Maybe someone else could clarify on that.

Kind Regards,

Aleksandr Slobodeniuk

Senior Software Engineer

+34 936 03 42 35

Carrer de Jordi Girona, 29

08034, Barcelona, Spain.

<http://fluendo.com>

<https://es.linkedin.com/company/fluendo>   <https://twitter.com/fluendo>
<https://github.com/fluendo>

On Thu, Apr 18, 2024 at 12:15 PM Deymos s via gstreamer-devel <
gstreamer-devel at lists.freedesktop.org> wrote:

> Thanks for your answer!
> I ended up with this
>
> 0:00:27.692477868  4754 0x556f02d60960 TRACE             GST_TRACER :0::
> object-alive, type-name=(string)GstQtSink,
> address=(gpointer)0x556f02fa8fb0, description=(string)<qtsink0>,
> ref-count=(uint)1, trace=(string);
> 0:00:27.692496306  4754 0x556f02d60960 TRACE             GST_TRACER :0::
> object-alive, type-name=(string)GstPad, address=(gpointer)0x556f02faa050,
> description=(string)<qtsink0:sink>, ref-count=(uint)1, trace=(string);
> 0:00:27.692503081  4754 0x556f02d60960 TRACE             GST_TRACER :0::
> object-alive, type-name=(string)GstGLWrappedContext,
> address=(gpointer)0x556f0329a610, description=(string)<glwrappedcontext0>,
> ref-count=(uint)1, trace=(string);
> 0:00:27.692508808  4754 0x556f02d60960 TRACE             GST_TRACER :0::
> object-alive, type-name=(string)GstGLWindowX11,
> address=(gpointer)0x556f0302cba0, description=(string)<glwindowx11-0>,
> ref-count=(uint)1, trace=(string);
> 0:00:27.692513557  4754 0x556f02d60960 TRACE             GST_TRACER :0::
> object-alive, type-name=(string)GstGLDisplayX11,
> address=(gpointer)0x556f02ff8650, description=(string)<gldisplayx11-1>,
> ref-count=(uint)4, trace=(string);
> 0:00:27.692518306  4754 0x556f02d60960 TRACE             GST_TRACER :0::
> object-alive, type-name=(string)GstGLContextGLX,
> address=(gpointer)0x7fd6b80190a0, description=(string)<glcontextglx0>,
> ref-count=(uint)1, trace=(string);
>
> but I still haven't found where and what isn't being deleted, it's
> probably a gl Video Item from qml.
> I am also interested in the question of changing the location in rtspsrc,
> what is the most correct tactic?
> 1. Change the rtspsrc state to NULL -> set a new location and run
> 2. Or delete and recreate the entire pipeline?
> In the first case, the memory increases anyway with the increase in the
> number of rtsp link restarts:(
>
> ср, 17 апр. 2024 г. в 18:51, Aleksandr Slobodeniuk via gstreamer-devel <
> gstreamer-devel at lists.freedesktop.org>:
>
>> Hi, this really sounds like a memory leak.
>> Quite likely that this will help:
>>
>> 1. set environment variables
>> GST_TRACERS="leaks(name=all-leaks)" GST_DEBUG=GST_TRACER:7
>> 2. make sure that your application calls `gst_deinit()` before it
>> terminates.
>> 3. run your app for a while (sounds like just opening 2 streams is
>> enough), and then close it (so everything gstreamer-related is supposed to
>> be freed, and the gst_deinit() is called afterwards).
>>
>> If some of the objects (such as elements, buffers) remain alive (it means
>> there was a leak) at the moment of gst_deinit(), it will print a warning to
>> stderr, and will log each object in the gstreamer log (also stderr by
>> default).
>>
>> If you have done all the steps and do not see any leak, it's quite useful
>> to add a leak on purpose to make sure the method works on your system. Like
>> just adding an extra ref on something.
>>
>> If it still only shows the leak you add on purpose, consider building
>> your project with address sanitizer, this will catch all the leaks, not
>> only in the GStreamer-related objects.
>>
>> Kind Regards,
>>
>> Aleksandr Slobodeniuk
>>
>> Senior Software Engineer
>>
>> +34 936 03 42 35
>>
>> Carrer de Jordi Girona, 29
>>
>> 08034, Barcelona, Spain.
>>
>> <http://fluendo.com>
>>
>> <https://es.linkedin.com/company/fluendo>   <https://twitter.com/fluendo>
>>   <https://github.com/fluendo>
>>
>>
>> On Wed, Apr 17, 2024 at 4:15 PM Deymos s via gstreamer-devel <
>> gstreamer-devel at lists.freedesktop.org> wrote:
>>
>>> I am developing a video wall for 32-64 streams, I faced the problem of
>>> increasing memory when restarting streams I have an example illustrating my
>>> problem.
>>> Example: https://github.com/Deymoss/Rtsp-player
>>>
>>> When I start the application, a pipeline is created, as a result, the
>>> application initially takes 54MB of RAM, when I start the stream, the
>>> volume increases to ~ 110 MB, when I close the stream, the memory is not
>>> freed, when I run the same stream again, the amount of RAM increases to 120
>>> MB, and so on, 36 streams eats 5 gb RAM for 12 hours, the same is true for
>>> file files descriptors (I suspect BUS creates them)
>>>
>>> How to properly clear the memory and all information about the stream
>>> when closing?
>>>
>>> At the moment I'm setting the pipeline to NULL and not making an unref,
>>> but if I uncomment these lines:
>>>
>>> gst_bus_set_sync_handler(m_videoPipe->bus, nullptr, nullptr, nullptr);gst_object_unref(m_videoPipe->pipeline);gst_object_unref(m_videoPipe->bus);
>>>
>>> nothing changes in memory consumption, although the refcount of each
>>> element and the pipeline itself at the end of the function is zero.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20240418/a1ac5bd2/attachment.htm>