Our application is multi-threaded where-in we have separate threads for:
1. Decoding the data (by calling vdec2 (h262) family functions) &
2. Display (which actually puts the data on display device display_put())
1. Decoding the data (by calling vdec2 (h262) family functions) &
2. Display (which actually puts the data on display device display_put())
Our application is based on the dvsdk demos, a buffer table is registered with vdec2 from which buffers are circulated between above mentioned decoder and display threads.
As we understand the masking mechanism is used with the buffers in the buffer table so that multiple entities (decoder & display) can share the same buffers amongst them and each entity frees its own mask once it completes work on the particular buffer.
We have encountered at least two scenarios where buffers get lost and are never used for further circulation.
Scenario 1:
It is seen that there are times when the decoder provides a buffer for display (by returning a buffer in Vdec2_getDisplayBuf()) but does not return the buffer as freed in the function call Vdec2_getFreeBuf(). As per dvsdk documentation and demos only buffers returned through Vdec2_getFreeBuf() should be marked codec free. This results in particular buffers codec mask never being removed rendering the buffer unusable for further iterations.
Scenario 2:
It is seen that sometimes a buffer is never returned through Vdec2_getDisplayBuf() but decoder simply returns it through Vdec2_getFreeBuf() which results in a scenario where the buffer stays in the buffer table with display mask because display mask can only be removed if the particular buffer was sent to display thread(this only happens when decoder gives out the buffer as display ready through Vdec2_getDisplayBuf()).Eventually, the buffer just stays in buffer table with display mask on and becomes useless for further circulation.
Scenario 1 & 2 result in threads being starved of buffers and finally getting hanged at fifo_get() calls in one of the said threads.
Can you please confirm and ellaborate on above mentioned scenarios.
