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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Hyunjun Ko from comment #8)
> (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?


I'm still wondering what is the issue with the approach we mentioned in
comment-3 and comment-4.

Now go back to the eg: use case you have explained:
If 4 buffers are in use, none of them are consumed by downstream yet, so you
are not supposed to replace the internal surface anyway.
If you get a buffer by calling acquire_buffer() it means no gstreamer element
in the pipeline is using it, the only possibility to have "buffer in use" is
msdk keeping a reference.

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