SDK / exoplayer

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

PiperOrigin-RevId: 525734520