GstBuffer life through pipeline

Matteo Pampolini matteo.pampolini at selexelsag.com
Thu Feb 9 08:47:58 PST 2012


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:
> On 02/08/2012 05:04 PM, Matteo Pampolini wrote:
>> 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.
> 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
>>
>> 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
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120209/ad0fe04b/attachment.htm>


More information about the gstreamer-devel mailing list