memory leak in rtpjitterbuffer

[Vnd]

Hi,

I am using similar pipeline as given below in my application to transcode RTP video.


gst-launch-1.0 udpsrc multicast-iface=eno2 uri=udp://239.0.11.11:6000 ! application/x-rtp,payload=33,clock-rate=90000 ! rtpjitterbuffer latency=2000 ! rtpmp2tdepay ! decodebin name=dec dec.! video/x-raw ! fakesink dec.! audio/x-raw ! fakesink

Above pipeline has memory leak. Memory reaches 90% within few hours and application crashes. Memory increase rate is random it is not linear, behaviour is not same across multiple runs.
I used GST_TRACE and valagrind tools to find out memory leak, but tools are not reporting anything

When I remove  rtpjitterbuffer  from the pipeline memory used is not increasing.

Any one facing similar issue ??
Is my pipeline is correct ?? I am configuring rtpjitterbuffer  buffer wrongly ??

I am using 1.10.0 for testing


~ Vinod

[Sebastian Dröge-3]

On Wed, 2016-12-21 at 19:06 -0800, Vnd wrote:

> Hi,
>
> I am using similar pipeline as given below in my application to transcode
> RTP video. 
>
>
> gst-launch-1.0 udpsrc multicast-iface=eno2 uri=udp://239.0.11.11:6000 !
> application/x-rtp,payload=33,clock-rate=90000 ! rtpjitterbuffer latency=2000
> ! rtpmp2tdepay ! decodebin name=dec dec.! video/x-raw ! fakesink dec.!
> audio/x-raw ! fakesink
>
> Above pipeline has memory leak. Memory reaches 90% within few hours and
> application crashes. Memory increase rate is random it is not linear,
> behaviour is not same across multiple runs. 
> I used GST_TRACE and valagrind tools to find out memory leak, but tools are
> not reporting anything

How are you running this in valgrind? With --leak-check=full and once
the application stops, valgrind reports no (big) memory leaks?

> When I remove  rtpjitterbuffer  from the pipeline memory used is not
> increasing.

Check if the rtpjitterbuffer is continuously growing for whatever
reason. Also check if valgrind's massif tool shows you something more
useful.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Vnd]

Thank you.
> How are you running this in valgrind? With --leak-check=full and once
> the application stops, valgrind reports no (big) memory leaks?

I am using below settings for valgrind test.
G_SLICE=always-malloc G_DEBUG=gc-friendly GLIBCPP_FORCE_NEW=1 GLIBCXX_FORCE_NEW=1 valgrind --log-file=leak.txt --track-origins=yes -v -q --tool=memcheck --trace-children=yes --num-callers=20 --read-var-info=yes --leak-check=full --leak-resolution=high --track-origins=yes

Valgrind is not reporting any memory leak in rtpjitterbuffer, there are few leaks which are init and can be neglected.

> Check if the rtpjitterbuffer is continuously growing for whatever
> reason. Also check if valgrind's massif tool shows you something more
> useful.
I have not used massif tool so far.
I will learn about the tool and see if massif gives some hint. I will come back with result.

~ Vnd

[Tim Müller]

On Thu, 2016-12-22 at 23:16 -0800, Vnd wrote:

Hi,

You could also try removing elements from the end of the pipeline, to
see if that makes any difference.

That is, first remove the decodebin and use rtpmp2tdepay ! fakesink.

Then try  rtpjitterbuffer ! fakesink

You could also try adding an identity drop-probability=0.95 or so after
udpsrc to see if it triggers the leak faster.

Cheers
-Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel