Separate MatrixTransformationProcessor constructors by color input and output.
PiperOrigin-RevId: 471034768
(cherry picked from commit 1b6482960e9240a7697c6a13fdde198e3bf375a1)
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
(cherry picked from commit 91709831ede920a38fc7dc3510973a434f390611)
Use the PQ OETF and EOTF to ensure that intermediate fragment shader operations
using PQ are in linear BT.2020 rather than PQ and HLG-1 BT.2020.
Also, swap the OETF and EOTF in shaders, as they were used incorrectly before
Manually tested by verifying transformer demo HLG and PQ videos look the same with and without this CL, including with a BitmapOverlayProcessor enabled to test flows both with one MatrixTransformationProcessor that skips HDR TFs, and with one that doesn't.
PiperOrigin-RevId: 469736067
(cherry picked from commit 2ad07e88ee39ed5f662df91dc7034bd0ce478abe)
Upstream timestamps from the decoder are also in microseconds,
so using microseconds here is consistent with that.
PiperOrigin-RevId: 468659099
(cherry picked from commit 0b1c540ff96b4f4f4ff7cff16a2e51674a42a0c2)
Adds a method to FrameProcessor.Listener to be called when an
output frame is available and a method releaseOutputFrame in
FrameProcessor allowing the caller to trigger release of the
oldest available output frame at a given timestamp. Late frames
or frames with unset release times are dropped in the
FinalMatrixTransformationProcessorWrapper.
More than one output frame can become available before they are
released if the penultimate GlTextureProcessor is capable of producing
multiple output frames. Processing continues while waiting for
releaseOutputFrame to be called. Frame release tasks are prioritized
over other tasks.
PiperOrigin-RevId: 468473072
(cherry picked from commit a5d7fdcab52ea6c12fa35efc348b69eccb53f715)
Manually tested using transformer demo HLG videos. Before this CL, RGB values after the YUV to RGB conversion reached up to 1.025. After this CL, RGB values correctly clamp at 1.0.
PiperOrigin-RevId: 468426092
(cherry picked from commit 244d38cf0e5640b6c07abaeebcaffce2d3913345)
FrameProcessingTaskExecutor should be released on error.
There can be a delay until this happens, so
FrameProcessingTaskExecutor will cancel any pending tasks
and drop new tasks until it is released.
PiperOrigin-RevId: 468171820
(cherry picked from commit 0c961a7abdc6ea7ef1b3f33dfd44d01459d2344a)
This is needed as a pre-requisite for allowing MCVR to control
FrameProcessor frame release for previewing.
Submitting a high-priority task is conceptually different from
posting at the front of a single queue of tasks, as the high-priority
tasks are executed in FIFO order among themselves. This will ensure
that frame release tasks submitted in close succession are executed
in the order they are submitted but before any lower priority tasks.
PiperOrigin-RevId: 467675137
(cherry picked from commit 59be732230fe9bfdc27c27d6a6866abacbdda3fe)
* Rename all Rgba instances to Rgb.
* Remove alpha value from the RGBA Matrices and apply the 4x4 matrix
only to the R, G, B channels.
* Restore the alpha from the input unchanged.
PiperOrigin-RevId: 467208888
(cherry picked from commit 8760ee48b910a4a34e6cc5008b660513203b05e8)
This change adds ExternalTextureManager which implements
InputListener to only queue input frames to the
ExternalTextureProcessor when it is ready to accept an input
frame. This replaces the old retry-logic in GlEffectsFrameProcessor.
Before this change, the retrying in GlEffectFrameProcessor wasted
CPU time if input becomes available faster than the
ExternalTextureProcessor can process it.
PiperOrigin-RevId: 467177659
(cherry picked from commit d7bf1ed2d7f5cd1e3893000d9d917ae69b814848)
This change adds a new method onReadyToAcceptInputFrame to
GlTextureProcesssor.InputListener and changes maybeQueueInputFrame
to queueInputFrame, removing the boolean return value.
This avoids the re-trying in ChainingGlTextureProcessorListener
by allowing it to only feed frames from the producing to the consuming
GlTextureProcessor when there is capacity.
MediaPipeProcessor still needs re-trying when processing isn't 1:1.
PiperOrigin-RevId: 466626369
(cherry picked from commit 97e6a86d2b1f72de9f95658f90ea40d1e1e4fac2)
While HDR is most closely tied to the color transfer (ex.
COLOR_TRANSFER_SDR is the only one explicitly mentioning dynamic
range), technically color spaces may be associated with HDR as well,
like BT.2020 commonly being used for HDR rather than BT.709 for SDR.
Therefore, it's more specific to mention just that the transfer is HDR.
PiperOrigin-RevId: 466316960
(cherry picked from commit 35161c748956d96e8e83cee007143615ef6f9d07)
This simplifies ChainingGlTextureProcessor as it now only connects a
consuming and a producing GlTextureProcessor rather than a previous,
current, and next GlTextureProcessor.
Also use default no-op implementations of the listeners in
SingleFrameGlTextureProcessor and MediaPipeProcessor to avoid
null-checks.
PiperOrigin-RevId: 466301642
(cherry picked from commit 7dc05edbab233dcd631a4a78ad65f1c30a1e9734)
This allows the GlEffectsFrameProcessor to later handle HLG and PQ
differently, or limited and full color range differently.
No functional change intended in this CL.
PiperOrigin-RevId: 466070764
(cherry picked from commit 536d42c865fd692c1d1799082077906287a2c3f0)
* Add RgbaMatrix interface implementation.
* Add Builder class for easy adjustments.
* Adjust existing RgbaMatrixPixelTests to use new RgbAdjustment class.
PiperOrigin-RevId: 465545429
(cherry picked from commit a76dbfd363e2d167b13d2bcd978979bcfd69b071)
* OpenGL automatically clamps the output colors to the [0, 1] interval.
PiperOrigin-RevId: 465071999
(cherry picked from commit 2347db5d7484b161f6389846e6cde5b0ac1ed7a6)
