-
Currently a gst buffer has one mfxFrameSurface when it's allocated and can't be changed. This is based on that the life of gst buffer and mfxFrameSurface would be same. But it's not true. Sometimes even if a gst buffer of a frame is finished on downstream, mfxFramesurface coupled with the gst buffer is still locked, which means it's still being used in the driver. So this patch does this. Every time a gst buffer is acquired from the pool, it confirms if the surface coupled with the buffer is unlocked. If not, replace it with new unlocked one. In this way, user(decoder or encoder) doesn't need to manage gst buffers including locked surface. To do that, this patch includes the following: 1. GstMsdkContext - Manages MSDK surfaces available, used, locked respectively as the following: 1\ surfaces_avail : surfaces which are free and unused anywhere 2\ surfaces_used : surfaces coupled with a gst buffer and being used now. 3\ surfaces_locked : surfaces still locked even after the gst buffer is released. - Provide an api to get MSDK surface available. - Provide an api to release MSDK surface. 2. GstMsdkVideoMemory - Gets a surface available when it's allocated. - Provide an api to get an available surface with new unlocked one. - Provide an api to release surface in the msdk video memory. 3. GstMsdkBufferPool - In acquire_buffer, every time a gst buffer is acquired, get new available surface from the list. - In release_buffer, it confirms if the buffer's surface is unlocked or not. - If unlocked, it is put to the available list. - If still locked, it is put to the locked list. This also fixes bug #793525. https://bugzilla.gnome.org/show_bug.cgi?id=793413 https://bugzilla.gnome.org/show_bug.cgi?id=793525
b08b8dda
