SDK / exoplayer

This partially reverts https://github.com/google/ExoPlayer/commit/9842fbab29a53a089f39e8e71fe9ed05d7d38d64
because our tests fail with 4.10 with an error like:

```
ShadowActivityThread.reset: ActivityThread not set
java.lang.NullPointerException: ShadowActivityThread.reset: ActivityThread not set
	at java.base/java.util.Objects.requireNonNull(Objects.java:246)
	at org.robolectric.shadows.ShadowActivityThread.reset(ShadowActivityThread.java:284)
	at org.robolectric.Shadows.reset(Shadows.java:2665)
	at org.robolectric.android.internal.AndroidTestEnvironment.resetState(AndroidTestEnvironment.java:657)
	at org.robolectric.RobolectricTestRunner.lambda$finallyAfterTest$0(RobolectricTestRunner.java:370)
	at org.robolectric.util.PerfStatsCollector.measure(PerfStatsCollector.java:86)
	at org.robolectric.RobolectricTestRunner.finallyAfterTest(RobolectricTestRunner.java:368)
	at org.robolectric.internal.SandboxTestRunner$2.lambda$evaluate$2(SandboxTestRunner.java:298)
	at org.robolectric.internal.bytecode.Sandbox.lambda$runOnMainThread$0(Sandbox.java:99)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
	at java.base/java.lang.Thread.run(Thread.java:830)
```

It looks like the code throwing this exception is new in Robolectric
4.10:
https://github.com/robolectric/robolectric/commit/65654a76ce6f166301ab1efb2047bab1998f8949

PiperOrigin-RevId: 527290033

In ASwB, all Transformer tests can be run by right-clicking on the project and
clicking "Run all tests". We cannot, however, select only some specific test
files within a project (ex. all non-analysis tests) to run tests on.

Add @Ignore to analysis tests, which are not intended to be run anyways
when determining whether Transformer is working on some device. These
tests also don't have proper skipping logic when a device doesn't support a
format, so they can't be run effectively on low-end devices anyways.

This eases manual testing, for example when debugging whether tests all pass
on a device.

When analysis tests are desired to be run, it should be easy to comment out
the @Ignore.

PiperOrigin-RevId: 527289600

PiperOrigin-RevId: 527271212

PiperOrigin-RevId: 527259619

This ensures the logic is consistent and can also be easily
used from custom UIs.

PiperOrigin-RevId: 527249127

Allow the VideoFrameProcessor to output to a texture without an output surface.

Tested by updating texture output tests to no longer output to a surface.

PiperOrigin-RevId: 527244605

The only dependencies that are not updated are the ones that need
to be kept in sync with other system (like Android source tree) or
would require a Kotlin dependency in common or exoplayer modules.

As a side effect, some demo apps now need a Kotlin config and some
additional modules require desugaring/multidex logic. To simplify
the setup, the desugaring and multidex steps are added to the common
config.

PiperOrigin-RevId: 527243950

This was only used in EncoderWrapper, so move createSupportedTransformationRequest
from VideoSamplePipeline to EncoderWrapper to reduce its scope.

PiperOrigin-RevId: 527226578

PiperOrigin-RevId: 527001582

The production code changes are in transformer, but the tests in effect have also been updated to confirm the is no color regression `inputColorInfo.colorTransfer=C.COLOR_TRANSFER_SRGB`

PiperOrigin-RevId: 526950435

PiperOrigin-RevId: 526940261

And minor fixes.

PiperOrigin-RevId: 526717927

PiperOrigin-RevId: 526683141

Previously, I assumed that SDR contents must be BT709, and HDR contents must be
BT2020. Turns out BT2020 is just wide-gamut, and SDR contents / transfers may be
represented in BT2020 color spaces.

Relax the check, so that we don't throw when valid BT2020 SMPTE 170M contents
are input into effects.

PiperOrigin-RevId: 526668347

PiperOrigin-RevId: 526655859

PiperOrigin-RevId: 526652129

PiperOrigin-RevId: 526642898

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/f92a9a628a3b2b8e189e583d209268b9d49d8978

*** Original commit ***

Bump Guava version to 31.1

***

***

PiperOrigin-RevId: 526601244

PiperOrigin-RevId: 526595567

Also clean-up a comment about skipping the NAL start code

To consistent with the other callsites of NalUnitUtil for parsing H265 SPS

This implicitly fixes a bug by removing the buggy implementation in H265Reader in favour of a working one. This change also adds tests to confirm the parsing bug is fixed.

This more closely matches the equations in equations 7-61 and 7-62 in
See H.265/HEVC (2014) section 7.4.8.

`prepare()` now logs a warning if it's called before `setPlayer()`
because it's not possible to tell if it's being called on the wrong
thread (since https://github.com/google/ExoPlayer/commit/9d028b33017e82b05a9de4e231355667b1b78264).

This change finds all the places one is called immediately after the
other and flips the order to be more correct.

Issue: androidx/media#350

#minor-release

PiperOrigin-RevId: 526582294

PiperOrigin-RevId: 526086973

#minor-release

PiperOrigin-RevId: 526082823

PiperOrigin-RevId: 526081541

The constructor is removed in https://github.com/google/ExoPlayer/commit/6dcb018da8fe9591173088be36a9a32a5a1eab31.

PiperOrigin-RevId: 526068585

And forward the id to the VolumeProviderCompat and read it from the platform
MediaController for compatibility.

PiperOrigin-RevId: 526046892

*** Original commit ***

Bump Guava version to 31.1

***

PiperOrigin-RevId: 526046600

This simplifies the addition of new fields in the future.

Also do some misc clean up for the volume limit values:
 - Add some documentation to mention assumed defaults
 - Add the IntRange annotations to match the ones we have in Player
   already
 - Mention the limits in the relevant Player methods
 - Avoid bundling default values
 - Improve range checks for masking in MediaController

PiperOrigin-RevId: 526029619

If the limited number of input buffers causes reading of all samples except the last one conveying end of stream, then the last frame will not be rendered.

PiperOrigin-RevId: 525974445

Whenever a frame is queued to the shader, it's guaranteed that there will be a
subsequent `onInputFrameProcessed` callback, so we can pass on the
end-of-stream signal there.

PiperOrigin-RevId: 525850141

PiperOrigin-RevId: 525761936

PiperOrigin-RevId: 525756451