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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #7 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Hyunjun Ko from comment #5)
> (In reply to sreerenj from comment #3)
> > Review of attachment 368614 [details] [review] [review]:
> > 
> > Overall looks good to me. One question,
> > Why can't we just release the buffer back to pool (within the custom
> > acquire_buffer method)if it is locked by msdk? Is there any particular
> > reason for keeping available & used surfaces in lists?
> > 
> 
> Think about this.
> - 5 buffers allocated are in the pool, 4 are used now.
> -> got 1 gst buffer, but its surface is locked, take it back to the pool.
> -> we retry to get new buffer.
> -> pool gives the same buffer since there is one allocated buffer. Take it
> back too -> Infinite loop. 
> 
> To handle this, we could keep the buffer instead of gst_buffer_unref before
> acquisition, but it would be very similar to the current implementation in
> decoder.
> 
> This case frequently happens when h264 decoding.
> 
> Another reson is in the reply of Victor's comment.


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?

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