bef3d518d2
After this CL, DVFP waits for flushing until all frames registered previously arrives. Previously, ETM records the difference between the number of registered frames, and the number of frames arrivd on the SurfaceTexture, when flushing. (Note that ETM is flushed the last in the chain, as flushing is done backwards from FinalShaderProgramWrapper). ETM then waits until the number of frames arrive after flush. The normal flow is, MediaCodecVideoRenderer (MCVR) registers a new decoded frame, in `processOutputBuffer()` to DVFP, MCVR call `codec.releaseOutputBuffer()` to have MediaCodec render the frame, and then the frame arrives in DVFP's ETM. However there might be a discrepancy. When registering the frame, ETM records the frame on the calling thread, ~instantly. Later when the rendered frame arrive, ETM records a frame is available on the task executor thread (or commonly known as the GL thread). More specifically, when a frame arrives in `onFrameAvailableListener`, ETM posts all subsequent processing to the task executor. When seeking, the task executor is flushed as the first step. It might be a frame that has already arrived on ETM, and the processing of such frame has already been queued into the task executor; only to be flushed as a result of flushing the task executor. If this happens, the frame is considered to be never have arrived. This causes a freeze on the app, because ETM'll wait until this frame arrives to declare flushing has completed. PiperOrigin-RevId: 631524332
Effect module
Provides functionality for applying effects to video frames.
Getting the module
The easiest way to get the module is to add it as a gradle dependency:
implementation 'androidx.media3:media3-effect:1.X.X'
where 1.X.X is the version, which must match the version of the other media
modules being used.
Alternatively, you can clone this GitHub project and depend on the module locally. Instructions for doing this can be found in the top level README.