appsink python memory leak?? unref call on sample? FIXED??

[Turmel, Frederic]

I think I figured out what is going on. Using GST_TRACE=mem-live was an eye opener. Using the debug flag showed that there was several thousand GST_Message variable allocated along with tsdemux type variable.

****So it turns out that any message not received/read in python are accumulating forever. That is, even if you don't ask for it.  TSdemux seems to be very chatty on the bus with the source I'm using. I'm getting several messages per seconds once I listen to the bus. These were eating memory.

Is this the correct behavior or that is a bug? Not sure if that is intended? 

So far, by adding the following below, I did not observe memory leak. (Print was just to see what's there)
That explains why gst-launch was not exposing the problem. It is probably good practice to listen to the bus but I was not expecting this to happen.

def on_message(bus, message):
    t = message.type
    print t
        
bus = pipeline.get_bus()
bus.add_signal_watch()
bus.connect("message", on_message)

 


-----Original Message-----
From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Turmel, Frederic
Sent: Friday, April 15, 2016 1:03 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?

Yes it is already set to false.  Same thing. I saw your post a while ago ;-) The thing is that even with without appsink straight to fakesink I see the issue so appsink is not the issue.

-----Original Message-----
From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Tim Müller
Sent: Friday, April 15, 2016 12:36 PM
To: gstreamer-devel at lists.freedesktop.org
Subject: Re: appsink python memory leak?? unref call on sample?

On Fri, 2016-04-15 at 19:09 +0000, Turmel, Frederic wrote:

Hi,

> Further test results, it looks like something is wrong with the python
> binding:
> 
> gst-launch-1.0 -v udpsrc uri=udp://239.1.1.1.1:5724 buffer-
> size=50000000 ! tsdemux program-number=1 ! fakesink  NO MEMORY LEAK 
> python udpsrc->tsdemux program-number=1->appsink    MEMORY LEAK python
> udpsrc->tsdemux program-number=1->fakesink   MEMORY LEAK
> 
> All test using the same multicast source and property. So it looks 
> like something is going with the python bindings. Any suggestion for 
> the next step?
> BTW is see the same behavior on 1.6.2 on windows
> 
> It is possible that tsdemux emit signals that the python binding 
> cannot handle?

Out of curiosity, could you try with

  fakesink enable-last-sample=false

?

If you use appsink, make sure to pull out samples.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel