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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Mar 28 22:04:01 UTC 2018


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

sreerenj <bsreerenj at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #370041|none                        |reviewed
             status|                            |

--- Comment #16 from sreerenj <bsreerenj at gmail.com> ---
Review of attachment 370041:
 --> (https://bugzilla.gnome.org/review?bug=793707&attachment=370041)

Q1)There is code to duplicate the fd, but I haven't seen a place which closing
it. Am I missing something here?


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.

::: 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).

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


More information about the gstreamer-bugs mailing list