If we can guarantee the lifetime of the fd is longer than
the memory, we can use DONT_CLOSE flag not to close when release.
But it's not provided in gstdmabuf yet while gstfdmemory does.
For example, in case of using VA-API or MSDK, we would need this api.
Otherwise we should call dup to duplicate the fd.
https://bugzilla.gnome.org/show_bug.cgi?id=794829
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
This class was made subclassable, though for future growth of the code,
it's better if we have some room for add class members. Using the small
padding since this is unlikely.
Adds "memory:DMABuf" caps feature. Since 1.11 tag.
Useful when the the dma-buf buffer cannot be mapped to CPU for r/w requests.
Example: protected content or platform constraints.
https://bugzilla.gnome.org/show_bug.cgi?id=759358
Makes it easier to track how many users there are
Also make it possible to create a dmabuf struct on systems without mmap,
it just won't be possible to map it.
https://bugzilla.gnome.org/show_bug.cgi?id=707793
In decide_allocation function some element may when to test the proposed allocator.
For example like this:
if (gst_query_get_n_allocation_params (query) > 0) {
GstAllocator * allocator;
GstAllocationParams params;
gst_query_parse_nth_allocation_param (query, 0, &allocator, ¶ms);
if (g_strcmp0(allocator->mem_type, GST_ALLOCATOR_DMABUF) == 0)
GST_DEBUG("got dmabuf allocator");
else
GST_DEBUG("got an other allocator");
}
https://bugzilla.gnome.org/show_bug.cgi?id=703659
Create new GstMemory and GstAllocator base on dmabuf.
Memory is not allocated/freed by userland but mapped/unmmaped
from a dmabuf file descriptor when requested.
This allocator is included in a new lib called libgstallocators
https://bugzilla.gnome.org/show_bug.cgi?id=693826
