memory not being freed?

[Spruyt, Randy]

Found the issue. Rookie mistake gst_buffer_unmap() was missing in the _fill() routine

From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Spruyt, Randy
Sent: Wednesday, May 06, 2015 2:48 PM
To: Discussion of the development of and with GStreamer
Subject: memory not being freed?

Hey Everyone,

This is my first source filter. The filter "produces" H.264 frames (from the nvidia frame buffer capture api). The frames show up in the d3dvideosink renderer correctly. When using a fakesink, memory usage is stable. However,  when using a avdec_h264 ! d3dvideosink, memory usage continually grows.

The only function we override from the base source class is the _fill() function.

If we have the _fill function do nothing and simply return GST_FLOW_OK, we have the same memory gowth problem, suggesting there is some kind of frame information missing designating the end of the frame. It seems like the element is holding on to the buffer and waiting for the remaining data in a subsequent buffer, that is never received, and thus the previous buffers are never freed. Everything renders correctly when using avdec_h264 ! d3dvideosink.

The question is: What is gstreamer looking for? What does it need to release the buffer references to previous frames so they can be freed? Maybe the caps are defined incorrectly?

Memory usage is fine:
gst-launch-1.0 christiedesktopcapturefilter ! fakesink

Memory usage grows continually:
Gst-launch-1.0 christiedesktopcapturefilter ! avdec_h264 ! fakesink
Gst-launch-1.0 christiedesktopcapturefilter ! h264parse ! fakesink
Gst-launch-1.0 christiedesktopcapturefilter ! avdec_h264 ! d3dvideosink

Cheers,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150508/a377763e/attachment.html>