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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #8 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to sreerenj from comment #7)
> 
> Assume it is a decoder.
> There are many possible cases:
> 
> a)the downstream using 4 buffers, (it would be too strange if downstream
> keep four buffers without releasing, but possible, maybe using queue before
> each postprocessing element)
> 
> b) Decoder is using those 4 buffers (then the "Locked" flag here should be 1
> too because the surfaces are being used by MediaSDK too)
> 
> 
> Currently, gst_msdk_video_memory_replace_surface() will try to replace a
> surface associated with the buffer if the acquire_buffer() returns a buffer
> which has locked flag set. 
> How can we guarantee that the surface-X (the new unlocked surface which
> supposed to replace the associated surface in acquired_buffer) is not
> required by dowstream anymore? Here the Msdk might have decreased the Lock
> count of Surface-X, but how can we ensure that the decoder already pushed
> this surface-X 
> downstream? Is it possible to have this surface-X been in a locked state for
> referencing and now decreased the lock count, but not yet pushed downstream?

Ah... that's a good point, IIUC.

To handle that, there should be 3 lists (avail, used, locked?) and then

- The used list : surfaces associated with the gst buffer acquired.
- The locked list : when releasing the buffer, if surface is still locked, we
put it to this list.
- The available list: the surfaces get unlocked in the locked list should move
to this list or surfaces that are never used.

we can search only the locked list without the used list when we need to
replace.

What do you think?

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