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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to sreerenj from comment #3)
> Review of attachment 368614 [details] [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.

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