H.264 Low Latency - sync put_DataFxn to MPU side
authorBuddy Liong <a0270631@ti.com>
Fri, 5 Feb 2016 22:53:27 +0000 (16:53 -0600)
committerBuddy Liong <a0270631@ti.com>
Mon, 2 Oct 2017 15:20:48 +0000 (10:20 -0500)
commitc18289251ef96f1453dac1c85628a3d84b8d3f07
treee5c47ce7c4b004b1a78ee9bc2e0df7cc08578c2f
parent7942b6bdafe15b8b3aefbb5894327c140a7e6504
H.264 Low Latency - sync put_DataFxn to MPU side

Prior to this, DCE Server returns H264D_PutDataFxn() to codec as
soon as put_DataFxn() has been sent to MPU side (libdce client).
This become an issue when codec has sent the last H264D_PutDataFxn()
which will return the VIDDEC3_process call.
On the MPU side, it is still busy processing the put_DataFxn() and
when MPU is receiving VIDDEC3_process, it stops the put_DataFxn() and
there could be one more put_DataFxn that needs to be processed.

Because of this there is an issue of numBlocks corruption.

The solution is to make sure DCE Server doesn't return H264D_PutDataFxn()
to codec unless MPU side (libdce client) has come with the next
put_DataFxn().
Basically DCE Server needs to make sure that MPU side has processed
the data in H264D_PutDataFxn() before return it to codec.
This is track in a variable "putdata_toclient".

When codec returns VIDDEC3_process(), DCE Server needs to set
the variable "putData_endprocess" so that the next put_DataFxn()
will return numBlocks = 0.
This will allow MPU side (libdce client) to stop sending put_DataFxn().

Change-Id: Ied8c03eec8d4934eb1218f8687ad5cff6d17d57f
Signed-off-by: Buddy Liong <a0270631@ti.com>
src/ti/framework/dce/dce.c