GNOME Bugzilla – Bug 735362
surface: add support for dma_buf imports
Last modified: 2015-01-28 16:39:12 UTC
This patch series from Feng Yuan makes it possible to import dma_buf memory into VA surfaces for further video processing.
Created attachment 284380 [details] [review] surface: add drm prime conversion to surface
Created attachment 284381 [details] [review] pluginbase: bind dma buffer to surface proxy
Created attachment 284382 [details] [review] makefile: add gstreamer-allocators for dma interface
Review of attachment 284380 [details] [review]: LGTM. DRM specific code should be moved to gstvaapisurface_drm.c though. This is also in view to supporting exports to dma_buf.
Review of attachment 284381 [details] [review]: propose_allocation() hook probably needs updates to report availability of dma_buf memory (capsfeatures). ::: gst/vaapi/gstvaapipluginbase.c @@ +156,3 @@ + return FALSE; + + mem = gst_buffer_get_memory (buf, 0); Memory leak here. gst_buffer_peek_memory() to only inspect things.
Review of attachment 284382 [details] [review]: ::: configure.ac @@ +274,3 @@ +dnl ... gst_dmabuf_memory_get_fd (gstreamer-allocators) +PKG_CHECK_MODULES([GST_ALLOCATORS], + [gstreamer-allocators-$GST_PKG_VERSION >= $GST_PLUGINS_BASE_VERSION_REQUIRED]) PKG_CHECK_MODULES() as it is written is a hard requirement. i.e. that's going to fail if this is not available. Needs proper guards until < 1.2.x code is definitely obsolete and removed.
Hi Gwenole, Thanks for your review. mem-leak issue was another fix which not uploaded here but in my local by 'gst_buffer_unref'. Thanks for the mem-leak finding and glad to see change to gst_buffer_peek_memory. Sorry that I'm busy on some other projects. please feel free to make any changes for dma buf support, I'm all ok. Thanks Wind
*** Bug 733951 has been marked as a duplicate of this bug. ***
An addition, for reference, the fd need to come as an array. It is desired, for certain usages, to have different dma_buf handles per plane. The Intel VA driver does not support that yet, however. It could, with a reasonable amount of work, down to libdrm for simplifying things.
Just curious, whether anyone tested the patches with v4l2src ? There is an io-mode dmabuf for v4l2src element in gstreamer.
(In reply to comment #11) > Just curious, whether anyone tested the patches with v4l2src ? > There is an io-mode dmabuf for v4l2src element in gstreamer. io-mode=dmabuf is only useful if the underlying driver supports dma_buf exports. uvcvideo does not support it, unless you use some RFC code. io-mode=dmabuf-import, available in GStreamer 1.4 IIRC, has the benefit to work with uvcvideo. However, it's cumbersome to setup. Ideally, we'd need an official capsfeature or some buffer pool config option. The current implementation uses a trick whereby dmabufs are exposed to sink pads. Tested with: ... ! v4l2src io-mode=dmabuf-import ! vaapipostproc format=i420 ! vaapisink BTW, the attached patches do not support io-mode=dmabuf, so I don't actually know how they were tested.
commit 011f9bd6cbdacc8b4cc8546aa24f505d3fa17a08 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Mon Sep 15 15:25:09 2014 +0200 surface: add support for dma_buf imports. Add new gst_vaapi_surface_new_with_dma_buf_handle() helper function to allow for creating VA surfaces from a foreign DRM PRIME fd. The resulting VA surface owns the supplied buffer handle. https://bugzilla.gnome.org/show_bug.cgi?id=735362 commit 667749c67e86413ebbe5e51647df6603a3f2dc26 Author: Wind Yuan <feng.yuan@intel.com> Date: Thu Jan 23 05:00:09 2014 -0500 plugins: add support for dma_buf imports. Allow imports of v4l2 buffers into VA surfaces for further operation with vaapi plugins, e.g. vaapipostproc or vaapiencode_* elements. https://bugzilla.gnome.org/show_bug.cgi?id=735362 [fixed memory leaks, ported to new dma_buf infrastructure, cleanups] Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>