SDK / exoplayer

Issue: #7882
PiperOrigin-RevId: 341394254

Move ownership of MediaCodec to MediaCodecAdapter so that all MediaCodec
interactions go through MediaCodecAdapter.

PiperOrigin-RevId: 341066926

PiperOrigin-RevId: 341051348

Add more MediaCodec methods to MediaCodedAdapter so that renderers
interact with the MediaCodec through the MediaCodecAdapter.

PiperOrigin-RevId: 341023452

In preparation for adding support for ads in playlists:
- Make releasing a no-op if the instance was already released
- Remove null checks on non-null `adDisplayContainer` and `adsLoader`
- Move initializing the ads manager into a private method as it will need to be
  called from two places soon.
- Misc other cleanup.

Issue: #3750
PiperOrigin-RevId: 341021493

Issue: #3750
PiperOrigin-RevId: 341021084

Issue: #3750
PiperOrigin-RevId: 341020676

PiperOrigin-RevId: 341019272

PiperOrigin-RevId: 341016263

- This change removes the last piece of logic that could cause deferred
  codec release (i.e., where the decision to release was made in
  processEndOfStream rather than in onInputFormatChanged.
- After this change, whether the codec will be released as a result of
  a format change is always established in onInputFormatChanged.

PiperOrigin-RevId: 341012403

PiperOrigin-RevId: 340915538

This fixes a case where updateCodecOperatingRate would configure
the decoder to be drained and then released, only for
onInputFormatChanged to override the drain action with something
else.

We've not seen any reports of this issue, which suggests that either
it's OK to not release the decoder in such cases, or that the
case doesn't happen very often. I suspect that it's both, but let's
restore the intended behaviour for now.

PiperOrigin-RevId: 340909132

PiperOrigin-RevId: 340826532

PiperOrigin-RevId: 340654217

Issue: #4904
PiperOrigin-RevId: 340654178

Issue: #4904
PiperOrigin-RevId: 340653126

PiperOrigin-RevId: 340651654

Issue: #5011
PiperOrigin-RevId: 340625816

Issue: #5011
PiperOrigin-RevId: 340621758

This information is already available in the MappingTrackSelector,
but not currently forwarded to the TrackSelection.Factory.

This makes it more complicated (or impossible) to depend on period
or manifest information in the track selection (for example to only
select tracks which are cached for the current format).

PiperOrigin-RevId: 340605886

Issue: #5011
PiperOrigin-RevId: 340477795

In a later change, the AdPlaybackState will include the playing adsId (set by
the AdsLoader) and the ads loader will use this to determine what ad
information is associated with the playing/next periods, to allow loading ads
in playlists.

Apps can continue to pass just a URI for an ad tag with their MediaItem, in
which case the associated playlist will request that ad tag just and the same
state will be used for all occurrences of the ad tag.

This change has breaking changes to the AdsLoader interface and removes
deprecated ways of passing the ad tag, as it's very likely to go into a major
release anyway and not needing to handle the deprecated cases simplifies
ImaAdsLoader.

Issue: #3750
PiperOrigin-RevId: 340438580

PiperOrigin-RevId: 340412910

This test is not run in presubmit as it was too flaky, and is currently broken
due to assets moving.

Also migrate off ImaPlaybackTest off deprecated APIs.

#minor-release

PiperOrigin-RevId: 340405666

PiperOrigin-RevId: 340314496

1. Move logic to decide to re-initialize the codec rather than using
   MediaCodec.setMediaDrmSession if (a) PlayReady is in use, and (b)
   the new session is still provisioning. This would previously have
   happened asynchronously after an input format change, after the
   decoder has subsequently been flushed. After this change the logic
   executes synchronously when the input format changes. This helps
   with the ref'd bug, since we want to propagate reasons for codec
   re-initialization through inputFormatChanged events.
2. Whilst moving the logic for re-initialization if PlayReady is
   being used, I fixed a bug that would occur when switching from
   [PlayReady --> non-PlayReady]. Re-use doesn't work in this case.
   The old logic only checked for the [Something --> PlayReady] case.
3. Remove pointless codec flush if updating the DRM session having
   not queued anything to the codec.

PiperOrigin-RevId: 340299790

- Support 32-bit A_PCM/FLOAT/IEEE PCM
- Support 8-bit and 16-bit A_PCM/INT/BIG PCM

#minor-release
Issue: #8142
PiperOrigin-RevId: 340264679

Issue: #5011
PiperOrigin-RevId: 340260636

PiperOrigin-RevId: 340254878

#minor-release

PiperOrigin-RevId: 340249019

- I don't think the session recovering later would work, because
  the codec will be configured not to use it.
- I'm not sure session recovery makes sense in general, and our
  implementations do not do this. Document it as a terminal state
  for now.

PiperOrigin-RevId: 340204194

This avoids confusion that currently exists between "operating rate"
and "codec operating rate", which are different. It also tightens the
requirement of the value being passed to be more than a "hint". It's
already being used as more than a hint for setting the Surface frame
rate.

PiperOrigin-RevId: 340201829

PiperOrigin-RevId: 340198099

Some content types always provide the license URL in the media.
The PlayReady example in the demo app doesn't provide a default
license URL for this reason, as an example.

#minor-release

PiperOrigin-RevId: 340125784

In a later change ImaAdsLoader will use multiple AdTagLoaders.

This change shouldn't have any substantial changes in behavior (it's almost
entirely moving code around). An exception is that ImaSdkSettings is configured
when making a request rather than at construction time.

Issue: #3750
PiperOrigin-RevId: 339891712

PiperOrigin-RevId: 339890695

These symbols will be referenced from AdTagLoader too in a later change.

PiperOrigin-RevId: 339889990

PiperOrigin-RevId: 339885432

PiperOrigin-RevId: 339864290

PiperOrigin-RevId: 339858492