SDK / exoplayer

 - The ExoPlayer docs will link to the media3 ones (for now, we can
   permanently redirect once no further stand-alone ExoPlayer release
   is published).
 - Contibuting issues and PRs should only happen on the media3 repo.
 - The media3 README is updated to remove any pre-release status
   information.

PiperOrigin-RevId: 516234594

* Add AudioDeviceCallbackApi23 class which extends the AudioDeviceCallback.
* Add registerAudioDeviceCallback and unregisterAudioDeviceCallback methods for Api23.
* Modify the logics of AudioCapabilitiesReceiver constructor, register and unregister methods.

PiperOrigin-RevId: 516183997

Log Format.colorInfo in EventLogger and the demo app's debug text.

#minor-release

PiperOrigin-RevId: 516172936

This change does basically three things in preparation of a follow
up CL that will insert ad breaks into multi-period live windows.

- Make sure that only `AdPlaybackState`s of multi-period streams
  are passed to `ImaUtil.splitAdPlaybackStateForPeriods()` from
  the media source.
- Enhance the splitting algorithm in ImaUtil to support live windows.
  Roughly, this includes calculating the window start position in the
  UNIX epoch context, handling the end period with an unknown duration
  and taking the `adResumePosition` of an ad group into account that
  affects the ad group start positions (`adGroup.timeUs`).
- Append a placeholder postroll ad group to the ad playback state of
  each period in a live stream to allow immediate transition to an
  ad that's inserted by an ad event from the SDK.

PiperOrigin-RevId: 516167958

To allow applying an effect only on a range of timestamps.

PiperOrigin-RevId: 515615662

PCM encoding is a property of decoded audio, however Transformer does
not output decoded audio.

PiperOrigin-RevId: 515580886

PiperOrigin-RevId: 515379858

The h265 encoding is getting covered in HDR test case (hdr10-720p.mp4) so having a separate asset is redundant here.

PiperOrigin-RevId: 515347662

PiperOrigin-RevId: 515297752

PiperOrigin-RevId: 515283537

The geodata is stored in the "udta" box as per MediaMuxer reference
https://cs.android.com/android/platform/superproject/+/master:frameworks/av/media/libstagefright/MPEG4Writer.cpp;drc=master;l=5588

PiperOrigin-RevId: 515095127

The value returned by `player.getContentPosition()` is calculated
in the timeline based on the position of the first period in the
window. In a single period live stream this position is advanced
when the live window advances on timeline refresh.

This calculation has produced slightly varying values below 1000
us which are likely caused by us/ms truncations for public API
values that we use in the IMASSAIMediaSource.

However, `AdGroup.timeUs` is the (recorded) content position at the
moment when the first ad of the an ad group has been inserted. While
playing an ad, we can always use this value instead of
`getContentPosition()` to not require recalculation.

#minor-release

PiperOrigin-RevId: 515093177

This change makes sure that the `AdPlaybackState` of any period can
contain an empty postroll placeholder.

The placeholder postroll should be represented in the `MediaPeriodId`
of a content period as `nextAdGroupIndex`, but should be ignored when
building the list of `MediaPeriodInfo` in the `MediaPeriodQueue`. This
is required to allow to add an ad group to ad playback state of the
content period that is currently being played, instantly insert an ad
period into the media period queue and immediately transition playback
to the new period.

This change makes sure and tests that

- a live server side inserted postroll placeholder can be inserted to
  a `AdPlaybackState` in well-defined and tested way (helper method)
- a postroll placeholder is NOT ignored when
  `AdPlaybackState.getAdGroupIndexAfterPositionUs` is called (this
   is required when evaluating the `nextAdGroupIndex`).
- a postroll placeholder is ignored when
  `AdPlaybackState.getAdGroupIndexForPositionUs` is called (this is
  required to not attempt to play the ad and is analogous to ignore the
  post roll placeholder in a single period timeline).
- `MediaPeriod.getFollowingMediaPeriodInfo()` does not include a
  `MediaPeriodInfo` for the placeholder postroll when building the
   queue.

PiperOrigin-RevId: 515079136

Test plan: run tests on ImageX with saving

PiperOrigin-RevId: 515068443

Split test/ TransformerEndToEndTest into SingleMediaItemEndToEndTest and
SingleSequenceEndToEndTest to reduce the file size and split the tests
by category.

PiperOrigin-RevId: 515039502

PiperOrigin-RevId: 515037497

These are only used from within the package, so demote them from public
to package-private.

PiperOrigin-RevId: 515029018

By making this method accept context, we can use DefaultDataSource.Factory in the DatasourceBitmapLoader to support a wider range on URI schemes in Bitmap Overlays. (and implement a local file picker for images for custom bitmap overlays in the demo transformer app)

PiperOrigin-RevId: 515013460

Per testing, using gamma 2.2 everywhere resulted in undesirable color
shifting.

PiperOrigin-RevId: 515008279

PiperOrigin-RevId: 515002313

Add TransformerAudioEndToEndTest to emulated tests.

PiperOrigin-RevId: 514991434

PiperOrigin-RevId: 514989776

Callbacks onTrackCount and onTrackAdded can be called simultaneously
from different threads.

Before this fix, it was possible for the MuxerWrapper and
FallbackListener track count to never be set, or to be set
with incorrect values.

PiperOrigin-RevId: 514779719

We currently rely on the raw playback head position to check if any
data is pending in the AudioTrack (e.g. to know if the renderer is
still ready). We can use the value returned from getCurrentPositionUs
instead to align the "isReady" logic with the playback position logic.

This has the side effect that getPlaybackHeadPosition position is called
less often when the position is obtained via getTimestamp.

PiperOrigin-RevId: 514747613

PiperOrigin-RevId: 514744747

PiperOrigin-RevId: 514728583

Segment timelines are technically allowed to be empty, but not all places
add the necessary checks.

Issue: google/ExoPlayer#11014
PiperOrigin-RevId: 514722205

PiperOrigin-RevId: 514720434

PiperOrigin-RevId: 514699994

This is only used within the same class, so can be private.

PiperOrigin-RevId: 514665000

PiperOrigin-RevId: 514575400

To create this file TextureInfo has been moved to common and renamed to GLTextureInfo.

We'll look to expand the interface in future to cover more of the methods around GL object maintenance in future as required.

PiperOrigin-RevId: 514445397

This clarifies that a SequenceAssetLoader loads data corresponding to an
EditedMediaItemSequence.

PiperOrigin-RevId: 514442681

PiperOrigin-RevId: 514436359

PiperOrigin-RevId: 514431184

- This is to make sure we know about all the tracks before initializing
the SamplePipelines. This allows to set the muxer and the fallback
listener track count before the SamplePipelines are built.
- As a result, the test files had to be updated because the order in
which the tracks are written has changed.
- The ImageAssetLoader also had to be updated to call onOutputFormat
repeatedly until it returns a non-null SampleConsumer.
- Also fix the trackCount sent to the muxer and fallback listener. The
correct track count can be computed now that we know about all the
tracks before building the SamplePipelines.

PiperOrigin-RevId: 514426123

Before, we used to never call glDeleteFramebuffers, which could
in theory lead to leaks in the number of frame buffers
available and make releasing the GL context more expensive.

PiperOrigin-RevId: 514387847

PiperOrigin-RevId: 514375835

Issue: google/ExoPlayer#11031

#minor-release

PiperOrigin-RevId: 514366016

Dackka generates a warning if a method has at least one `@param` tag,
but not all of them are documented.

#minor-release

PiperOrigin-RevId: 513873453