[Bug 793707] msdk: Add dmabuf support in msdk plugins

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793707

--- Comment #22 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to sreerenj from comment #16)
> Review of attachment 370041 [details] [review]:
> 
> Q1)There is code to duplicate the fd, but I haven't seen a place which
> closing it. Am I missing something here?

In gstfdmemory, it's closed when releasing the memory.

> 
> 
> Q2)Another thing I have noticed is the confusion in preallocation of buffers:
> When the GsttBufferpool preallocate the minimum number of buffers (when
> gstbufferpool activate the pool) there are few things happening:
> The basecalss allocate the buffer (default_start() implementation) and push
> back to the pool by invoking the release_buffer(). But we have our own
> release_buffer implementation which
> will invoke gst_msdk_context_put_surface_available(). As a result, during
> preallocation we use the same mfxFrameSurface1 in each buffer creation.
> It can work with out any issue, but I want to make sure that it is the
> expected behavior.

Yeah, I knew this. 
I did decide to let it be since it doesn't cause any problem.

> 
> ::: sys/msdk/gstmsdkbufferpool.c
> @@ +310,3 @@
> +      gst_buffer_unset_flags (buf, GST_BUFFER_FLAG_TAG_MEMORY);
> +    }
> +    gst_msdk_get_dmabuf_info_from_surface (surface, &fd, NULL);
> 
> I'm totally confused here!
> It seems gst_dmabuf_memory_get_fd (gst_buffer_peek_memory (buf, 0)) != fd)
> will be always "TRUE".
> 
> What I can see is that the gst_msdk_dmabuf_memory_new_with_surface() always
> duplicate the fd, but once you do "new_fd = dup(old_fd) ", new_fd and fd
> will have different values.
> Which means, the fd attaching to the memory will never gonna match with
> surface->fd (in any iteration).

Correct. This is a bit related to the Qeustion 1.
gst_dmabuf_allocator_alloc calls just gst_fd_allocator_alloc with
GST_FD_MEMORY_FLAG_NONE flag. But we need to set GST_FD_MEMORY_FLAG_DONT_CLOSE
flag but we can't with gstdmabuf.h

If we calls gst_fd_allocator_alloc with GST_FD_MEMORY_FLAG_DONT_CLOSE(which is
possible but not sure if it's proper), things got different.

In addition, I didn't find out any other solution other than replacing memory.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.