Buffer destruction at sink

[ivan aponte]

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 ? 

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.

Is the memory in GstMapInfo is contiguous? Does gst_buffer_map implies a   memory copy operation  ?

Thanks for your answers. Regards, 

Ivan 

--

Iván Aponte

[phone]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

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


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[ivan aponte]

thanks for your prompt answer. 

On Sun, Mar 20, 2016 at 5:10 AM Sebastian Dröge <[hidden email]> wrote:

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--

Iván Aponte

[phone]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel