<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hello Stefan, many many thanks, I had a deeper look into GStreamer queue element and putting it into our pipeline with the appropriate property values fixed our issues. Your help was very precious to us! Best regards, Matteo On 08/02/2012 20:14, Stefan Sauer wrote: <blockquote cite="mid:4F32C9A5.5040905@hora-obscura.de" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> On 02/08/2012 05:04 PM, Matteo Pampolini wrote: <blockquote cite="mid:4F329D0C.5090204@selexelsag.com" type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Hello there, my name is Matteo and together with my group I'm developing a quite complex video-surveillance application based on GStreamer (Windows). For simplicity you can imagine a window with a grid layout with many concurrent videos showing in their respective area and fetching data through RTSP/RTP. We noticed that if we make any change that in some way slows down or stops the visualization the memory heap starts increasing very fast until the process inevitably crashes. Then I tried to insulate the issue by simply using gst-launch with an RTSP/RTP source and putting a very silly while(1)  Sleep(500); inside the show_frame function of videosink plugin (in our case d3dvideosink), and the problem is easily reproduced. </blockquote> Are you having unbound queues in your pipeline? The videosink will usually discard late buffers. If it does not run, upstream elements would be stalled. If there are queues in the upstream graph, the blocking would only go to the queue and the elements on the other side would fill up the queue. If the queue is limited it would stop the upstream elements once its full. Stefan <blockquote cite="mid:4F329D0C.5090204@selexelsag.com" type="cite"> Can you please try to give me an idea of the lifetime of GstBuffer through the pipeline? I mean, the heap issue is surely caused by a continuous allocation of GstBuffer's by the RTP source without a corresponding free when they are consumed, but who is in charge of this? Why isn't there a mechanism that checks the consumer status and eventually stops the producer? Many thanks in advance for your kind support, Matteo <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ gstreamer-devel mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </pre> </blockquote> </blockquote> </body> </html>