SDK / exoplayer

PiperOrigin-RevId: 416521346

Before the introduction of the MediaCodecAdapter, users could get
access directly to the MediaCodec instance from
MediaCodecRenderer.getCodec() and then retrieve the codec metrics.

This change exposes MediaCodec.getMetrics() on the MediaCodecAdapter.

Issue: google/ExoPlayer#9766

#minor-release

PiperOrigin-RevId: 416343023

This is a no-op because all the <resource> elements from these XML
files are effectively concatenated together during building.

PiperOrigin-RevId: 416326534

The same condition is checked further up on L497 already.

PiperOrigin-RevId: 416324687

PiperOrigin-RevId: 416314200

PiperOrigin-RevId: 416307600

PiperOrigin-RevId: 416289790

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/0aa23b08b1624cacc9414cd093ff64ca1e0b1a10

*** Original commit ***

Add capability flags for hardware and decoder support

Issue: google/ExoPlayer#9565

***

***

PiperOrigin-RevId: 416285603

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/27f905f571c0594e9140b9a8a4264affb1c000de

*** Original commit ***

Don't sort decoders by format support in supportsFormat

This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.

This is n...

***

PiperOrigin-RevId: 416269130

*** Original commit ***

Don't sort decoders by format support in supportsFormat

This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.

This is necessary groundwork for a subsequent change that will
indicate in Capabilities whether the decoder that suppports the
format is the primary one as specifi

***

PiperOrigin-RevId: 416170612

*** Original commit ***

Add capability flags for hardware and decoder support

Issue: google/ExoPlayer#9565

***

PiperOrigin-RevId: 416170329

TransformationException will be used for all errors that occur
during a transformation.

PiperOrigin-RevId: 416032504

This change adds a delegate class that loads and forwards calls
to a Spatializer with reflection, so that we can use the Spatializer
API before we update the compile SDK target to 32.

PiperOrigin-RevId: 416027289

The Robolectric implementation of HttpURLConnection forwards to the JRE
implementation [1], which behaves differently to the Android one
available on devices and emulators. For these tests to be a realistic
test of the HTTP stack used in real playbacks we can't use Robolectric.

Similar to https://github.com/google/ExoPlayer/commit/df0e89c1678ff0dda00bb187be05b8198bd31567

[1] https://github.com/robolectric/robolectric/issues/6769#issuecomment-943556156

PiperOrigin-RevId: 416013662

Fix the gradle problem

PiperOrigin-RevId: 416011494

Breaks the gradle build

PiperOrigin-RevId: 415999600

The version in the android tree was updated in
https://cs.android.com/android/_/android/platform/external/guava/+/8337762fe0ca3a07056d30318a7df2444c1a0284

PiperOrigin-RevId: 415988097

By including the full counters in the failure message we have a clearer
insight into the cause of the failure.

PiperOrigin-RevId: 415982732

PiperOrigin-RevId: 415529751

UnsupportedEglVersionException() is only used once, and seems a bit too
specific for Transformer. Also, it's possible for eglCreateContext to fail for
other reasons besides lack of support, so it wasn't always accurate when
thrown.

It is possible for devices not to support EGL version 2.0 though, per
https://source.android.com/devices/graphics/implement-opengl-es, which doesn't
specify the EGL version that must be supported.

PiperOrigin-RevId: 415489396

tl;dr:
In the previous transformer, the transcoding flow is

- If a the GL's input surface (from decoder) does not have data, wait 10ms
 (DO_SOME_WORK)
- Else, make the decoder render **ONE** frame to the GL's input surface
  - Wait at least 10ms, until the frame's texture is available
  - Then process the texture

The process is quite slow, so in the new version, we do:
- If a the GL's input surface (from decoder) does not have data, wait 10ms
 (DO_SOME_WORK) **same**
- Else, make the decoder render **as many frames** to the GL's input surface
  - Process **as many** available textures in this DO_SOME_WORK cycle

PiperOrigin-RevId: 415474722

*** Original commit ***

Make audio track min buffer size configurable.

Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.

The new class is easily configurable and highly tested.
Manual test was used to catch any regression.

https://github.com/google/ExoPlayer/issues/8891

***

PiperOrigin-RevId: 415469179

The input rotation is used to rotate the video during decoding, the
video is rotated so that it is in landscape orientation before encoding
and a rotation is added to the output format where necessary so that
the output video has the same orientation as the input.

PiperOrigin-RevId: 415301328

Refactor GlUtil.java to be a bit more readable. Also, reorder, inline, and
rename a few things. Refactoring change only. No functional changes intended.

PiperOrigin-RevId: 415283874

For DASH manifests, we merge min/max live latency values from various
sources and they may not be consistent with each other. To ensure we
use a sensible configuration in all cases, we can add more correctness
checks:
 1. Limit the min/max values to fall into the available live window.
 2. Ensure that maxLatency >= minLatency in all cases.

Issue: google/ExoPlayer#9750
PiperOrigin-RevId: 415282938

PiperOrigin-RevId: 415279434

PiperOrigin-RevId: 415272874

Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.

The new class is easily configurable and highly tested.
Manual test was used to catch any regression.

https://github.com/google/ExoPlayer/issues/8891

PiperOrigin-RevId: 415268938

Issue: google/ExoPlayer#9565
PiperOrigin-RevId: 415235358

Null was equivalent to DEFAULT_AUDIO_CAPABILITIES.
In favor of null safety, remove the null state.

PiperOrigin-RevId: 415037404

Being able to see the output of the GL pipeline is useful for debugging. For
example, when we previously saw flakiness it would have been useful to be able
to tell quickly whether the output looked wrong without needing to run a
transformation to the end then inspect the output file, and when working on
support for HDR editing it's useful to be able to do manual testing on devices
that don't support HDR encoding (but do support decoding/processing it with
GL).

Also change the progress indicator to be linear as this looks better in the
demo app when shown next to the debug preview.

PiperOrigin-RevId: 414999491

This is a no-op change that updates supportsFormat to use the
decoder list before it's reordered by format support. Instead,
supportsFormat iterates through the decoders listed in their
original priority order as specified by the MediaCodecSelector.
The end result is identical.

This is necessary groundwork for a subsequent change that will
indicate in Capabilities whether the decoder that suppports the
format is the primary one as specified by the MediaCodecSelector
(i.e., the one at index=0 in the lists that are now used).

Issue: google/ExoPlayer#9565
PiperOrigin-RevId: 414971986

The color set via textAppearance is overridden by any non-null
textColor set directly on the style. We always want the specific
properties the textAppearance specifies, so set them directly to
prevent them from being overridden.

#minor-release
Issue: google/ExoPlayer#9765
PiperOrigin-RevId: 414967143

PiperOrigin-RevId: 414804513

This more accurately reflects the value stored in this field.

PiperOrigin-RevId: 414762892

Configure MediaCodec in API 32+ to always output 99 channels
so that we use the audio is spatialized, if the platform can apply
spatialization to it.

In a follow-up change, the output channel count will be set based on the
device's spatialization capabilities.

PiperOrigin-RevId: 414751543

`DefaultAudioSink` already has 3 telescoping
constructors and an other one would be have been
needed to add a buffer size tuning option.

PiperOrigin-RevId: 414703366

The existing code creates an imbalance between `inputBufferCount` and
`droppedBufferCount` by adding 'dropped source buffers' to
`droppedBufferCount` but not to `inputBufferCount`. This results in
assertion failures in `DashTestRunner`.

PiperOrigin-RevId: 414672175

#minor-release

PiperOrigin-RevId: 414671861

It's been observed that some devices fail when releasing a secure codec
attached to a surface and immediately trying to create a new codec
(secure or insecure) attached to the same surface. This change catches
all exceptions thrown during codec creation, sleeps for a short time,
and then retries the codec creation. This is observed to fix the problem
(we believe this is because it allows enough time for some background
part of the previous codec release operation to complete).

This change should have no effect on the control flow when codec
creation succeeds first time. It will introduce a slight delay when
creating the preferred codec fails (while we sleep and retry), which
will either delay propagating a permanent error or attempting to
initialize a fallback decoder. We can't avoid the extra delay to
instantiating the fallback decoder because we can't know whether we
expect the second attempt to create the preferred decoder to succeed or
fail. The benefit to always retrying the preferred decoder creation
(fixing playback failures) outweighs the unfortunate additional delay
to instantiating fallback decoders.

Issue: google/ExoPlayer#8696
#minor-release
PiperOrigin-RevId: 414671743