author | Buddy Liong <a0270631@ti.com> | |
Fri, 5 Feb 2016 22:53:27 +0000 (16:53 -0600) | ||
committer | Buddy Liong <a0270631@ti.com> | |
Mon, 2 Oct 2017 15:20:48 +0000 (10:20 -0500) | ||
commit | c18289251ef96f1453dac1c85628a3d84b8d3f07 | |
tree | e5c47ce7c4b004b1a78ee9bc2e0df7cc08578c2f | tree | snapshot (tar.xz tar.gz zip) |
parent | 7942b6bdafe15b8b3aefbb5894327c140a7e6504 | commit | diff |
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>
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 | diff | blob | history |