[Bug 755072] vaapi: expose memory:DMABuf capsfeature

Fri Feb 3 18:23:16 UTC 2017

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

--- Comment #64 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
I have pushed these commits

commit b0016e336bba268e4eb9968ff7847932711e07db
Author: Víctor Manuel Jáquez Leal <victorx.jaquez at intel.com>
Date:   Sun Oct 16 01:04:09 2016 +0100

    vaapidecode: don't GLTextureUpload if dmabuf

    Do not add the meta:GstVideoGLTextureUploadMeta feature if the render
    element can handle dmabuf-based buffers, avoiding its negotiation.

commit 25e8309567167321b1a596235f1114bc4a9da960
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 16:21:21 2016 +0100

    vaapidecode: make pool to export decoder's surface

    Use new -base API gst_video_decoder_allocate_output_frame_full() to
    pass the current proxy/surface to the pool.

    The pool will will export thins given surface instead of exporting a
    brand new surface that will never be filled in with meaningfull data.

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

commit 50242eaaf7a14abfa4f62308a808b9d7e7950b1d
Author: Víctor Manuel Jáquez Leal <victorx.jaquez at intel.com>
Date:   Fri Feb 3 17:06:29 2017 +0100

    plugins: decoder can negotiate dmabuf downstream

commit 9ed73e76afba6b88ca50b0b8c94cfecf6995f35e
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 16:07:07 2016 +0100

    vaapivideobufferpool: override acquire_buffer()

    Overriding the vmethod acquire_buffer() it is possible to attach the
    right GstMemory to the current acquired buffer.

    As a matter of fact, this acquired buffer may contain any instantiated
    GstFdmemory, since this buffer have been popped out from the buffer
    pool, which is a FIFO queue. So there is no garantee that this buffer
    matches with the current processed surface. Evenmore, the VA driver
    might not use a FIFO queue. Therefore, it is no way to guess on the
    ordering.

    In short, acquire_buffer on the VA driver and on the buffer pool return
    none matching data, we have to manually attach the right GstFdMemory to
    the acquired GstBuffer. The right GstMemory is the one associated with
    the current surface.

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

commit 6a0375d96eae0378d19f5c450a278516e5d16305
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 16:05:04 2016 +0100

    vaapivideomemory: export surface if it is provided

    gst_vaapi_dmabuf_memory_new() always exports a surface. Previously, it
    had to create that surface. Now it can also export an already provided
    surface. It is useful to export decoder's surfaces (from VA context).

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

commit 9132510ce090f1a6e7279f19c230fdea8aae0b4c
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 15:55:27 2016 +0100

    vaapivideobufferpool: add GstVaapiVideoBufferPoolAcquireParams

    Useful to let the pool know the current surface proxy when calling
    gst_buffer_pool_alloc_buffer() / gst_buffer_pool_acquire_buffer()

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

commit 4f037a036bf138607df201e73ff3ff0f8fa449b4
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 15:09:34 2016 +0100

    libs: surface: add gst_vaapi_surface_{set,peek}_buffer_proxy()

    These functions are useful when a dmabuf-based memory is instantiated in
    order to relate the generated buffer @proxy with the processed @surface.

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

commit 7fc1b70ff65bc5a78181e1faa23b4e5e510f8c3b
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 15:07:31 2016 +0100

    libs: bufferproxy: gst_vaapi_buffer_proxy_{set,peek}_mem()

    This patch adds a GstMemory as a variable member of the buffer proxy,
    because we will need to associate the buffer proxy with the memory
    which exposes it. Later, we will know which memory, in the video buffer
    pool, is attached to the processed surface.

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

commit bc97987ffb5a5d5699fcb53a9413f9e8b4e525f2
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 15:33:41 2016 +0100

    vaapipostproc: don't GLTextureUpload if dmabuf

    Do not add the meta:GstVideoGLTextureUploadMeta feature if the render
    element can handle dmabuf-based buffers, avoiding its negotiation.

    Similar as "vaapidecode: do not add meta:GstVideoGLTextureUploadMeta
    feature if can dmabuf"

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

commit aa20508bcfd1109b1fd522b0fba0f5f7f48a1d73
Author: Víctor Manuel Jáquez Leal <victorx.jaquez at intel.com>
Date:   Fri Dec 16 14:12:30 2016 +0100

    plugins: enable DMAbuf allocator to downstream

    If the negotiated caps are raw caps and downstream supports the
    EGL_EXT_image_dma_buf_import extension, then the created allocator
    is the DMAbuf, configured to downstream.

    At this moment, the only element which can push dmabuf-based buffers
    to downstream, is vaapipostproc.

commit 37b774393413aec9c444bc45f08be2bf385e3be2
Author: Víctor Manuel Jáquez Leal <victorx.jaquez at intel.com>
Date:   Thu Jun 2 22:13:51 2016 +0200

    plugins: check if negotiate dmabuf with downstream

    In order to enable, in the future, dmabuf-based buffers, the vaapi base
    plugin needs to check if downstream can import dmabuf buffers.

    This patch checks if downstream can handle dmabuf, by introspecting the
    shared GL context. If the GL context is EGL/GLES2 and have the extension
    EGL_EXT_image_dma_buf_import, then dmabuf can be negotiated.

    Original-patch-by: Julien Isorce <j.isorce at samsung.com>

commit 33af1fc5786a179a22ecb9c43021ddd24c382263
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 15:37:04 2016 +0100

    vaapivideomemory: release proxy's data if downstream

    The surface created for downstream is going to be filled by VAAPI
    elements. So, the driver needs write access on that surface.

    This patch releases the derived image held by the proxy, thus the
    surface is unmarked as busy.

    This is how it has to be done as discussed on libva mailing list.

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

commit 69a2406a20335ce045c4c67a9ff98e2c96d143c9
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 15:01:04 2016 +0100

    libs: bufferproxy: add gst_vaapi_buffer_proxy_release_data()

    Adds an API to request the user's data release in the buffer proxy.

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

commit fbed3c3366da9a544069d2d472949d5f31b63e5d
Author: Julien Isorce <j.isorce at samsung.com>
Date:   Wed Oct 19 15:27:03 2016 +0100

    vaapivideomemory: add direction to dmabuf allocator

    Add GstPadDirection param to gst_vaapi_dmabuf_allocator_new(), thus
    we later could do different thing when the allocated memory is for
    upstream or dowstream, as required by VA-API.

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

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