Managing reference count of GstBuffers created in GstBaseSrc

[Tim-Philipp Müller]

On Tue, 2022-10-25 at 20:09 +0000, Dass, Reena Collins via gstreamer-
devel wrote:

Hi Reena,

> I have a pipeline that has a GstPushSrc, some GstTransforms
> andGstBaseSink.
>  
> This pipeline runs continuously. I noticed the GstBuffers created in
> the GstTransform modules have their reference count decremented when
> they are pushed to the next element in the pipeline but the one
> created in GstPushSrc. As a result the memory usage keeps on
> increasing with time.  I could not find documentation anywhere that
> talks about how and why the buffers reference counting is done.
>  
> I would appreciate it if somebody has some insight or could point me
> to some documentation that talks about the reference counting.

Did you mean "but _not_ the one created in GstPushSrc"?

Generally speaking, when a buffer is passed from one element to the
next, the (possibly shared) ownership of the buffer (i.e. the ref) is
passed from one element to the next. The reason for this is that the
writability of the buffer is linked to the refcount of the
buffer+memories attached to it. If the buffer is shared (refcount >= 2)
an element can't just write into the existing buffer because that would
affect the other owner(s). But if the refcount is == 1 the receiving
element knows it can do in-place transforms without copying should it
wish to do so.

Are these elements custom element or standard GStreamer ones?

If the GstBaseTransform does an in-place transform (or passthrough) of
the input buffer from the GstPushSrc, it will pass ownership on to the
next element (sink?) after doing so, in which case the sink would be
responsible for unreffing it when the time comes. Sinks often keep the
last buffer around until the next one arrives (can be disabled with
enable-last-sample=false).

If the GstBaseTransform does a transform from the input buffer into a
new output buffer it is responsible for unreffing the old buffer when
it's done.

There are also things like buffer pools, in which case buffers get
recycled into the pool when they're about to be destroyed.

In any case, if you use the base classes they should take care of
everything for you in this respect already really.

If there are custom elements involved, perhaps they're missing a
gst_buffer_unmap() call somewhere after a gst_buffer_map()?

Cheers
 Tim