SDK / exoplayer

No functional changes.

PiperOrigin-RevId: 472245797
(cherry picked from commit 8e14611d)

PiperOrigin-RevId: 471782565
(cherry picked from commit 87926f0b)

shouldPassthrough's internal checks seem to be check whether we should *not*
pass through, which seemed a bit like a confusing double-negative to me.

shouldTranscode is slightly more clear, by instead returning true when we do
want to transcode.

No functional changes intended.

PiperOrigin-RevId: 471753771
(cherry picked from commit 1a4cd549)

https://github.com/google/ExoPlayer/commit/3b0d2c15867b3698f130476736785d427b28b7bd made `shouldPassthrough` always return false for `enableHdrVideoEditing`:

>We force using `FrameEditor` (no passthrough) to avoid the need to select another edit operation, and use the new shaders. The `EGLContext` and `EGLSurface` also need to be set up differently for this path.

However, this was introduced before the `videoNeedsEncoding` setting was introduced in https://github.com/google/ExoPlayer/commit/3f615040c033a37f81b1d73605cd1f7d420b47b5. That setting should apply to HDR videos as much as SDR videos.

PiperOrigin-RevId: 471569853
(cherry picked from commit 94713a8f)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment) (3 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 471198016
(cherry picked from commit bac7d697)

PiperOrigin-RevId: 471137219
(cherry picked from commit 90e684a6)

In particular, make it a bit more clear that "rendering" and "releasing" frames are
related concepts, and how they differ from one another in conjunction with frame
dropping.

PiperOrigin-RevId: 471037733
(cherry picked from commit e6a1936b)

Separate MatrixTransformationProcessor constructors by color input and output.

PiperOrigin-RevId: 471034768
(cherry picked from commit a8e814ab)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment) (19 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 471022923
(cherry picked from commit 674b3d45)

PiperOrigin-RevId: 471017440
(cherry picked from commit 9f67ce4e)

PiperOrigin-RevId: 471008623
(cherry picked from commit cb60f506)

#minor-release

PiperOrigin-RevId: 470999044
(cherry picked from commit e285e707)

* Non-standard parameter comment; prefer `/* paramName= */ arg`
  (see http://go/bugpattern/ParameterComment)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if there's an issue with the CL content.
* File a bug under go/rosie-bug if there's an issue with how the CL was managed.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.
PiperOrigin-RevId: 470953422
(cherry picked from commit f26e5d4c)

This should now expect transformation to succeed.

PiperOrigin-RevId: 470950411
(cherry picked from commit 1023254d)

PiperOrigin-RevId: 470354448
(cherry picked from commit f1a3a40e)

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 a8c54dd3)

Native multidex can only be used for binaries with minSdkVersion of 21 or higher, but minSdkVersion was specified to 16.

PiperOrigin-RevId: 470004102
(cherry picked from commit a395b23d)

Native multidex can only be used for binaries with minSdkVersion of 21 or higher, but minSdkVersion was specified to 16.

PiperOrigin-RevId: 470003836
(cherry picked from commit 142d1c06)

Remove unecessary null checks.

PiperOrigin-RevId: 469999952
(cherry picked from commit f454c9aa)

PiperOrigin-RevId: 469959215
(cherry picked from commit 0f48c89f)

PiperOrigin-RevId: 469750922
(cherry picked from commit 2c70383d)

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 a2139109)

PiperOrigin-RevId: 469443086
(cherry picked from commit 5cf166c1)

PiperOrigin-RevId: 469438747
(cherry picked from commit 9a1e7fbd)

`android_binary` is only required when building an application.

PiperOrigin-RevId: 469413752
(cherry picked from commit f01896af)

PiperOrigin-RevId: 469143613
(cherry picked from commit c6114355)

PiperOrigin-RevId: 468672505
(cherry picked from commit 010ecec8)

Issue: androidx/media#142
PiperOrigin-RevId: 468666737
(cherry picked from commit d6442f63)

Upstream timestamps from the decoder are also in microseconds,
so using microseconds here is consistent with that.

PiperOrigin-RevId: 468659099
(cherry picked from commit 4e7f9c57)

Remove the manual overwriting of Note ON events that have 0 velocity with Note OFF. JSyn handles this already.

- The implementation of "running status" means that the amount of bytes read from the file differ from the size of the sample that ends up in the decoder. The decoder sample contains the applied running status (status of previous event), which the file bytes don't contain.

PiperOrigin-RevId: 468537659
(cherry picked from commit 53218b50)

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 2c063546)

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 32ee4480)

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 d11c3be9)

PiperOrigin-RevId: 468152718
(cherry picked from commit c6a10ad2)

PiperOrigin-RevId: 468013019
(cherry picked from commit 977370e9)

We create an empty CueGroup in many places as default or
where none is needed. Instead, we can define a constant
for this purpose and reuse it.

PiperOrigin-RevId: 467944841
(cherry picked from commit 29208ec1)

PiperOrigin-RevId: 467910378
(cherry picked from commit 130a5362)

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 4d81a6db)

Increase the estimated max sample size for HEVC by 2x, and set a minimum
size of 2MB. The 2MB will be applied for resolutions up to 1080p, after
which the new calculation takes effect. This is in par with the
platform's HEVC software decoder.

PiperOrigin-RevId: 467641494
(cherry picked from commit d3d5ffce)

The specified CMake version doesn't work with the latest
Android Studio releases. Updating to a more recent version
fixes the problem.

Issue: google/ExoPlayer#9933
PiperOrigin-RevId: 467634063
(cherry picked from commit 80b635e7)