Buffer destruction at sink

Sebastian Dröge sebastian at centricular.com
Sun Mar 20 09:40:07 UTC 2016


On So, 2016-03-20 at 01:53 +0000, Iván Aponte wrote:
> Hello, 
> 
> I am programming  a sink plugin which basically gets the memory from
> a buffer, maps it to the gpu (since we have zerocopy available) and
> executes a cuda kernel. I am using the basesink class as a base for
> my sink.   I have some questions:  
> 
> Should I unref the buffer at the end of the render function or is it
> automatically unreffed when the render function returns ? 

render() only gives you a reference for the scope of the function call
and will unref it afterwards. If you need to keep another reference
around, you need to ref() it.

> Why  gst_buffer_ref is potentially a memory copy operation? is this
> true even if it is in the render function of basesink ? I just don't
> want the memory to get freed.

ref() is not going to copy the buffer, where did it say that it might
copy? What can happen though is that ref() causes a copy elsewhere.

Reason for that is that only a buffer with a reference count of exactly
one is considered writable. If something wants to write to a buffer
with a higher reference count, a copy would have to be done first.
gst_buffer_make_writable() would do that.

In case of your sink you wouldn't really have to worry about that.

> Is the memory in GstMapInfo is contiguous?

It's contiguous virtual memory, not necessarily physically contiguous.
It's behaving like a memory area returned by malloc().

>  Does gst_buffer_map implies a   memory copy operation  ?

It might, depending of the underlying memory and if the buffer has 1 or
multiple GstMemory stored inside it.

In many cases it is doing nothing other than giving you a pointer. If
it is backed by normal system memory and there is exactly one GstMemory
in the buffer.

But for example memory based on GL textures might involve downloading
data from the GPU and then uploading it again on unmap. (which might be
async, or not, the implementation decides that).

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160320/abd23551/attachment-0001.sig>


More information about the gstreamer-devel mailing list