appsink python memory leak?? unref call on sample?
Frederic.Turmel at arris.com
Tue Apr 12 15:14:38 UTC 2016
Hi sebastian, I made some progress, I removed python from the equation to try to pin point where the leak is happening. Currently testing with 1.8 on windows and ubuntu1.8 in parallel.
Gst-launch-1.0 udpsrc (receiving multicast) ! tsdemux program-number=101 ! h264parse ! avdec_h264 ! fakesink
That pipeline started at 70MB to end up 1.7GB after overnight test (8 hours) on windows
gst-launch-1.0 -v udpsrc (receiving multicast) ! tsdemux program-number=101 ! fakesink
That pipeline started at 12172B to 13428B after 8 hours will keep monitoring ubuntu w1.8
gst-launch-1.0 -v udpsrc (receiving multicast) ! tsdemux program-number=102 ! h264parse ! fakesink
That pipeline started at 12764B to 13892 after 8 hours will keep monitoring Ubuntu w1.8
I also see that 1 memory leak (EIT) was fixed in tsdemux right after 1.8 was build that could potentially contribute to this but that would be really small.
I'm starting more test to see if avdec_h264 is the culprit.
From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Sebastian Dröge
Sent: Monday, April 11, 2016 11:48 PM
To: Discussion of the development of and with GStreamer <gstreamer-devel at lists.freedesktop.org>
Subject: Re: appsink python memory leak?? unref call on sample?
On Di, 2016-04-12 at 02:59 +0000, Turmel, Frederic wrote:
> Hi, I’m observing a slow memory leak with the app sink in python. I’m
> using appsink to receive raw video frame from a decodebin.
> In the C API I see that we need to call “gst_sample_unref(sample)”
> after reading the sample
> Is there an equivalent in python?
> The leak does not seems to be cause by a frame buffer leak since the
> leak is really small and a frame leak would be much bigger than what
> I’m seeing.
> Pipeline is udpsrc->tsdemux->decodebin->appsink
> Any information will be appreciated.
Please provide some code to reproduce the problem. Then we can decide if it's a problem in your code or in the Python bindings, it's probably the latter though.
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
More information about the gstreamer-devel