GstBuffer life through pipeline
Stefan Sauer
ensonic at hora-obscura.de
Wed Feb 8 11:14:45 PST 2012
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/20120208/d3ae3a5d/attachment.html>
More information about the gstreamer-devel
mailing list