Re: Release RAM, when close or reload stream

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 <
[email protected]>:

> 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 <
> [email protected]> 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.
>>
>