Details
When running a video decode pipeline on DM365 with a queue element between the
decoder and sink, the error &quot;failed to get a free contiguous buffer
from BufTab&quot;
appears.
I notice that Rendezvous_force() is called by the dmai transport buffer object
in its finalize routine. But what if the buffer is still locked by the codec in
which case the codec_FREE usemask would be still set on the buffer.

Details
When running a video decode pipeline on DM365 with a queue element between the
decoder and sink, the error &quot;failed to get a free contiguous buffer
from BufTab&quot;
appears.
I notice that Rendezvous_force() is called by the dmai transport buffer object
in its finalize routine. But what if the buffer is still locked by the codec in
which case the codec_FREE usemask would be still set on the buffer.

You have raised very valid point and iirc me and Don was talking about this
other day. And unfortunately neither of us got time to debug this further. It
will be helpful if you can debug and report your finding.

I was thinking that Vdec2_getDisplayBuf(....) will return buffer from output tab
only when codec free's those buffers. At this point i'm not sure if its DMAI or
gstreamer issue here.

FYI, Asheesh found some issue with dmai buffer chunk API during his transcoding
use case and was suspecting that it holds true for 365 as well. May be you also
need to refer his comments here.
https://gstreamer.ti.com/gf/project/dmai/tracker/?action=TrackerItemEdit&amp;tracker_item_id=1024&amp;tracker_id=1024

Hi Brijesh,
Sorry for the late response.
This problem occurs because the tidmaibuffertransport object which is a GObject
is owned only by itself while the DMAI buffer object associated with the object
could have multiple owners specified by various useMasks(the codec for
instance).
Hence when a tidmaibuffertransport is free'd, the finalize fn. would be invoked
even if the associated DMAI buffer is locked by the codec.
To overcome this, we could make the codec also do a gst_buffer_ref of the
tidmaibuffertransport and call gst_buffer_unref when the associated DMAI buffer
is free'd by the codec.
Ofcourse, this would mean that, given the DMAI buffer Object, one should be able
to get the associated tidmaibuffertransport object, while only the other way
round is possible as of now.
We did this by modifying DMAI.
I guess a better way to handle this would be to bring in a
parent-&gt;child(transport-&gt;buffer) relationship by GObjectifying the
DMAI buffer as well.