GStreamer RTSP client memory increase irregularly


I have created an rtsp client using Gstreamer.

After running the program, the memory usage increases for a while.
Then it maintains a constant memory usage.

However, there are cases where the memory increases to 0.01 MB irregularly.

Is there any way to solve the problem?

This is my pipeline.

    g_pipeline = gst_pipeline_new ("new pipeline");

	source = gst_element_factory_make ("rtspsrc", NULL);
    depay = gst_element_factory_make ("rtph264depay", NULL);
    parse = gst_element_factory_make ("h264parse", NULL);
    decode = gst_element_factory_make ("nvv4l2decoder", NULL); 
    sink = gst_element_factory_make ("appsink", NULL); 
	fps_sink = gst_element_factory_make ("fpsdisplaysink", NULL);
	filter1 = gst_element_factory_make ("capsfilter", NULL);
	filter2 = gst_element_factory_make ("capsfilter", NULL);
	conv = gst_element_factory_make ("nvvidconv", NULL);

    GstCaps    *caps1, *caps2;
    caps1 = gst_caps_from_string ("video/x-raw(memory:NVMM)"); 
    caps2 = gst_caps_from_string ("video/x-raw"); 
    g_object_set (G_OBJECT (filter1), "caps", caps1, NULL);
    g_object_set (G_OBJECT (filter2), "caps", caps2, NULL);
    gst_caps_unref (caps1);
    gst_caps_unref (caps2);

    gst_bin_add_many(GST_BIN(g_pipeline[m_uniqueId]), source, depay, parse, decode, filter1, conv, filter2, fps_sink, NULL);
	gst_element_link_many (depay, parse, decode, filter1, conv, filter2, fps_sink, NULL);
	g_signal_connect(source, "pad-added", G_CALLBACK(new_pad_call_back0), NULL);
	g_signal_connect(sink, "new-sample", G_CALLBACK(new_sample0), NULL);

I use following options.

    g_object_set(G_OBJECT(sink), "emit-signals", true, NULL); 
    g_object_set(G_OBJECT(sink), "async", false, "sync", false, "max-lateness", 0, NULL);
    g_object_set(G_OBJECT(sink), "max-buffers", 1, NULL); 
    g_object_set(G_OBJECT(sink), "drop", true, NULL); 
    g_object_set(G_OBJECT (source), "latency", 0, NULL);

    g_object_set (G_OBJECT (fps_sink), "text-overlay", false, "video-sink", sink, NULL);
    g_object_set (G_OBJECT (fps_sink), "sync", false, NULL);

It looks fine from the description. Probably the minor increase is cache. Could you try a long run(2-3 days) and check if the streaming is still alive. If there is memory leak, you should see the preocess being killed by OOM killer.

You may also refer to the link to clean the cache for a try:

I have a few more questions.

Is it okay to create a pipeline for multiple threads and get the image buffer from the new-sample callback?

When two or fewer threads get the image buffer from each new-sample callback, the memory usage becomes constant after a certain period of time.
After that, the memory usage increases irregularly.

However, it seems that memory usage continues to increase when you do it on three or more threads.

Please try with avdec_h264. If you don’t observe the same with avdec_h264, probably it is a potential issue in nvv4l2decoder. If you have confirm it, please share a test app so that we can reproduce the issue.


I tested nvv4l2decoder for a long time and it took up almost all the memory.

So I change jetpack from 4.2.1 to 4.4.

And then I am testing how much memory the nvv4l2decoder and omxh264dec uses.
Is it okay to test two hardware decoder plug-ins at the same time on one board?

Memory is still irregularly increasing below 0.1MB.
But It does not happen often.
Does this happen occasionally?

I plan to record the increase in memory by tomorrow.


This is my test result.
I will continue testing until next Monday.

It should be noted. When there is nobody in the office, there is no memory increase.
There is no memory increase at night.
I think it’s because I only use cameras.

It seems that buffering works internally with simultaneous use of IP cameras and network traffic. I don’t know why the memory never shrinks again.

JetPack 4.4 , check memory usage for omxh264dec decoder plugin
1280 x 720 four ip camera, use rtspsrc

7/23 16:21 1118.82MB
7/23 16:44 1119.03MB ( +00:23, +00:21MB )
7/23 17:16 1119.07MB ( +00:12, +00:04MB )
7/24 08:31 1119.12MB ( +15:15, +00:05MB )
7/24 09:24 1119.13MB ( +00:53, +00:01MB )
7/24 09:42 1119.14MB ( +00:18, +00:01MB )
7/24 09:50 1119.15MB ( +00:08, +00:01MB )

JetPack 4.4 , check memory usage for nvv4l2decoder decoder plugin
1280 x 720 four ip camera, use rtspsrc

7/23 16:21 779.71MB
7/23 16:34 781.04MB ( +00:13, +01.33MB )
7/23 16:51 781.05MB ( +00:17, +00.01MB )
7/23 16:59 781.07MB ( +00:08, +00.02MB )
7/23 17:38 781.09MB ( +00:39, +00.02MB )
7/23 18:16 781.14MB ( +00:38, +00.05MB )
7/23 18:51 781.19MB ( +00:35, +00.05MB )
7/24 08:31 781.32MB ( +13:40, +00.13MB )
7/24 08:41 781.34MB ( +00:10, +00.02MB )
7/24 09:22 781.36MB ( +00:41, +00.02MB )
7/24 09:29 781.37MB ( +00:07, +00.01MB )
7/24 09:43 781.38MB ( +00:14, +00.01MB )
7/24 09:47 781.39MB ( +00:04, +00.01MB )

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one and share a test app so that we can reproduce the issue