[Bug 793413] msdk: manage mfxFrameSurfaces seperately with other surfacepool.

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to Víctor Manuel Jáquez Leal from comment #4)
> This decoupling of surfaces and gst-buffers, worries me, since it adds
> complexity.
> 
> I wonder the same as Sree, is it possible, in
> gst_msdk_buffer_pool_acquire_buffer(), look like:
> 
> do {
>   ret =
>       GST_BUFFER_POOL_CLASS (parent_class)->acquire_buffer (pool, &buf,
> params);
> 
>   if (ret != GST_FLOW_OK || !priv->use_video_memory) {
>     if (buf)
>       *out_buffer_ptr = buf;
>     return ret;
>   }
> 
>   surface = gst_msdk_get_surface_from_buffer (buf);
> 
>   if (surface->Data.Locked == 0) {
>     out_buffer_ptr = bug;
>     return ret;
>   } else {
>     gst_buffer_unref (buf);
>   }
> } while (surface->Data.Locked > 0)
> 
> I mean, keep the 1:1 relation of buffer and surface, just adding an
> additional check for MSDK locking.

Multiple call of vmethod in one gst_buffer_pool_acquire_buffer?
I don't believe it's good and the design of gstbufferpool is attempting this
kindof usage.

For example, in the customed method, we should do increase/decrease outstanding
when we do unref and acquire, and which is already in
gst_buffer_pool_acquire_buffer. But there's no way to do it since it's private.

And ref of pool to the buffer should be in the customed method, which is also
in gst_buffer_pool_acquire_buffer.

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