Re: Release RAM, when close or reload stream

about asan:
sorry, I wanted to write  ASAN_OPTIONS=detect_leaks=0 , so asan leak
detection won't fail the build itself.
Also another note is that it doesn't detect leaks on Windows.

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 1:42 PM Aleksandr Slobodeniuk <
[email protected]> wrote:

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