-
Notifications
You must be signed in to change notification settings - Fork 6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix ExternalTextureManager: repeated queueing input frame in preview
TL;DR: we should check if there are new frames available to queue to the ExternalTextureProcessor before actually queueing a frame. The overall flow on the external texture processor: - `SurfaceTexture.onFrameAvailable` is called on `ExtTexMgr`, and - it calls `updateTexImage()`, and sets `frame` - it calls `maybeQueueFrameToExtTexProc()` - the frame is queued to `ExtTexProc` if `frame` is set - From `ExtTexProc.queueInputFrame()`: - notifies the `frameProcessorListener` of available frame - notifies the `inputListener` of `onReadyToAcceptInputFrame` - (`ExtTexMgr` is the listener), it calls `maybeQueueFrameToExtTexProc()` again -- Parallelly -- - `ExtTexProc` calls `inputListener.onInputFrameProcessed`, when the frame is released - (`ExtTexMgr` is the listener), sets `frame` to `null` *Problem* This logic relies on `frame` to be cleared at the right time. In transformer, it's OK b/c `ExtTexProc` release the frame immediately in `queueInputFrame()` and calls `onInputFrameProcessed` which also reset `frame` But in previewing, the frame is not released for a while, up to 10 ms. In this case, `frame` will not reset in this 10 ms, and `maybeQueueFrameToExtTexProc()` is repeatedly queueing the same input frame. PiperOrigin-RevId: 470211620
- Loading branch information
1 parent
a395b23
commit a8c54dd
Showing
1 changed file
with
21 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters