SDK / exoplayer

This test file used to be remote, which led to various errors in loading the file or timing out during the muxer or overall transformer.

export4k60 test timing on Pixel 7:

|Condition                 |elapsedTimeMs|AS Test "Duration" (s)|
|--------------------------|-------------|----------------------|
|local file (this CL)      |4253         |14                    |
|Remote file, googleguest  |5510         |17                    |
|Remote file, 4G           |11423        |25                    |

PiperOrigin-RevId: 516815462

With the Mp4Muxer, while writing a large file if the something unexpected happens and muxer is not closed properly then it still outputs a valid MP4 file with partial data.

PiperOrigin-RevId: 516572804

#minor-release

PiperOrigin-RevId: 516550914

While playback thread is 'asleep' during audio offload playback, the playbackInfo.positionUs is not being constantly updated. During this time, the returned value from getCurrentPosition should return an estimate based on the most recent value and playback speed.

PiperOrigin-RevId: 516550509

- To support looping EditedMediaItemSequences, we need a way to tell the
AssetLoader that a sample couldn't be consumed and that it should retry
later. This is necessary in case we don't know yet whether the looping
sequence should load more samples because the other sequences haven't
made sufficient progress yet.
- The decision on whether to consume a sample is based on its timestamp
so it needs to be available.

PiperOrigin-RevId: 516546026

Instead of using a long frameDurationUs with Math.floor, use a double
frameDurationUs with Math.round,

Before, playing an image with 30 fps over 1 second would result in the final
timestamp not being aligned to the expected 1 second timestamp. Over long
periods of time, this can lead to significant timestamp drift. Additionally,
for TimestampWrapper and constrained multi-asset, where TimestampWrapper
begins the 2nd effect on the 2nd asset's startTimeUs, this floor() behavior
can lead to the first few frames of the 2nd asset using the first asset's
effects, due to timestamps being mismatched.

PiperOrigin-RevId: 516529240

#minor-release

PiperOrigin-RevId: 516514583

PiperOrigin-RevId: 516499906

This test is not run on emulator, triage or postsubmit, and does not
provide value to the library in it's current state. It could be
deleted, however it still may have use for analysis of exported files
on MH.

PiperOrigin-RevId: 516491160

PiperOrigin-RevId: 516478351

PiperOrigin-RevId: 516314175

PiperOrigin-RevId: 516300480

 - 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