author | Buddy Liong <a0270631@ti.com> | |
Fri, 5 Feb 2016 22:53:27 +0000 (16:53 -0600) | ||
committer | Buddy Liong <a0270631@ti.com> | |
Tue, 1 Mar 2016 21:43:16 +0000 (15:43 -0600) | ||
commit | 030572aaa1964bb50a903852fab0ecc0149b6b7e | |
tree | ea70526272ef77d86829bff72778254d045e7207 | tree | snapshot (tar.xz tar.gz zip) |
parent | 266749c0b6a2584d563625f881f998c3d78ca873 | 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 |