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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to sreerenj from comment #11)
> (In reply to Hyunjun Ko from comment #10)
> > Gstbufferpool doesn't know if a buffer is in use in the driver as you know.
> > If there are 5 allocated buffers, 4 in use, 1 in release (but still being
> > used in the driver)  the pool always gives the buffer to the user when
> > calling acquire_buffer.
> > 
> 
> "4 in use": means you are not supposed to replace the surface in any of
> those 4 buffers. Those are already acquired by either decoder or downstream.
> So our only choice is to check whether the last one available buffer.

Sure

> In this case, the infinite loop can be avoided by trying only a specific
> number of times (eg: try till the count reach the size of gstbufferpool).

In this way, we should implement something like allocation new buffer in the
pool if we reach the count, which is implemented already in gstbufferpool. I
don't think it's good. This is similar reason to comment 6.

> 
> The point is that "release_buffer" will always release buffer back to pool
> irrespective of whether MSDK keeping the lock for referencing. 

That's why I suggested 3 lists instead of 2 lists.

> 
> Am I missing something?

I'm confused what you mean.

I thought you wanted to simplify the code by somethign like:
in acquire_buffer, just getting a buffer and then if it's locked, just
unreffing and getting a new buffer again, without managing something by list.

Totally I agree with it if poosible without duplicated(or ugly) code.
If you want to see a patch implementing your thought, I would do that.
Do you want?

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