SDK / exoplayer

Move static factories into a separate class and make it implement an interface
that will let tests customize encoder/decoder creation.

PiperOrigin-RevId: 417610825

Inspired by my investigation of Issue: google/ExoPlayer#9797

#minor-release

PiperOrigin-RevId: 417609076

The spec renamed this type of playlist in the latest revision
to use a more inclusive technical term (see
https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-10)

PiperOrigin-RevId: 417560274

PiperOrigin-RevId: 417428182

The old name is kept in exoplayer2.

PiperOrigin-RevId: 417378759

PiperOrigin-RevId: 417378468

PiperOrigin-RevId: 416848472

To support multi-period content we need to store AdPlaybackStates and
SharedMediaPeriod by the periodUid as a key. While after this no-op CL,
we still only support single-period content, storing these resources by
periodUid is the ground work for multi-period support being added in an
follow-up CL.

PiperOrigin-RevId: 416836445

This method has been deprecated since 2.12.0:
https://github.com/google/ExoPlayer/commit/d1bbd3507a818e14be965c300938f9d51f8b7836

PiperOrigin-RevId: 416827149

Keep the old interface deprecated so any app code implementing it by
name (rather than with a lambda) will continue to work.

PiperOrigin-RevId: 416816566

PiperOrigin-RevId: 416809105

PiperOrigin-RevId: 416795667

These comments inadvertantly refer to types and drawables associated
with Player(Control)View.

PiperOrigin-RevId: 416794967

Transformer uses ExoPlayer for reading input. Apps using Transformer
do not need to know this. So, PlaybackExceptions are converted to
TransformationExceptions with the same message, cause and error code.

The corresponding IO error codes are copied from PlaybackException.

PiperOrigin-RevId: 416793741

We check the fraction of the available duration we have already
buffered for live streams to see if we can increase the quality.
This fraction compares against the overall available media duration
at the time of the track selection, which by definition can't include
one of the availabe chunks (as this is the one we want to load next).

That means, for example, that for a reasonable live offset of 3 segments
we can at most reach a fraction of 0.66, which is less than our default
threshold of 0.75, meaning we can never switch up.

By subtracting one chunk duration from the available duration, we make
this comparison fair again and allow all live streams (regardless of
live offset) to reach up to 100% buffered data (which is above our
default value of 75%), so that they can increase the quality.

Issue: google/ExoPlayer#9784
PiperOrigin-RevId: 416791033

Use TransformationException for codec and audio processor
initialization problems instead.

PiperOrigin-RevId: 416765510

Format.NO_VALUE should only be used for Format fields.

PiperOrigin-RevId: 416646415

PiperOrigin-RevId: 416613846

PiperOrigin-RevId: 416543473

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