SDK / exoplayer

r2.9.5

When calling releaseSource(), all pending messages will be removed. That means
that all action-on-completion callbacks which are somewhere in flight are
just dropped without being called. This change adds code to keep track of the
current state of each callback to allow all of them being called when the
source is released.

Issue:#5464
PiperOrigin-RevId: 232312528

That was previously handled by the player. But since we switched to Handler
messages instead of player messages, we should do that manually.

PiperOrigin-RevId: 229341747

We currently either use the app thread returned by the player or the thread
the commands are called on depending on whether the media source is already
prepared or not.

This change lets the application decide which callback thread to use. As a
side effect, we also don't longer need access the player instance passed to
MediaSource.prepare.

PiperOrigin-RevId: 227871111

Imported from GitHub PR https://github.com/google/ExoPlayer/pull/5462

Pull request for the following issue: #5421
Merge d9d88b079c4ca0533a836b2715a65b924babbb89 into a7381916

PiperOrigin-RevId: 232335113

The Util class already handles removeMessages calls but so far ignored calls
to removeCallbacksAndMessages.

PiperOrigin-RevId: 232312458

Issue: #4519
PiperOrigin-RevId: 232299233

PiperOrigin-RevId: 231772920

Issue: #4468
PiperOrigin-RevId: 231759438

PiperOrigin-RevId: 231644908

Prevents collisions with SCTE-35 subtitles.

Issue:#5330
PiperOrigin-RevId: 230195494

If there is data after the last samples in the container, we may request
continue loading after the last samples have been read but before the load has
completed. In this situation the buffered position is returned as
Long.MAX_VALUE, which prevents continuing loading, yet the media period is not
treated as fully buffered because its buffered position is not
C.TIME_END_OF_SOURCE.

PiperOrigin-RevId: 231406964

Float output is only possible from API 21, but the high-res int
to float conversion path was checking for 32-bit PCM not float
output capability.

PiperOrigin-RevId: 231172495

PiperOrigin-RevId: 231171425

This brings in a memory leak fix.

Issue: #4114
PiperOrigin-RevId: 230880521

PiperOrigin-RevId: 230743198

PiperOrigin-RevId: 230734189

r2.9.4

ExoPlaybackExceptions of type SOURCE are always associated with the loading
period and thus we can use the event time for the loading period in
onPlayerError. Renderer and unexpected exceptions are still associated with the
currently playing period.

Issue:#5407
PiperOrigin-RevId: 230216253

PiperOrigin-RevId: 230213842

Change the dependency to the new monolithic GVR SDK target.

PiperOrigin-RevId: 229931549

The Amlogic awesome decoder reduces the video size of interlaced videos by half
if the internal configuration isn't force reset with new maximum input size
values. The product of these new values must exceed 1920x1088 to force the
reset.

Issue:#5003
PiperOrigin-RevId: 230206675

Issue:#5402
PiperOrigin-RevId: 229758525

That's the same position set in MediaPeriod.prepare (where it may be removed
in the future).

Having the position at an earlier point is necessary to fix an
issue with lazy preparation in ConcatenatingMediaSource where the prepare
position was assumed to be known but MediaPeriod.prepare hasn't been called
yet.

Issue:#5350
PiperOrigin-RevId: 229756637

Issue: #5344
PiperOrigin-RevId: 229527963

When the extra adaptation set of a switch group isn't defined in the manifest, we
currently assume it's the first adaptation group. This either leads to wrong grouping
or duplicate track groups.

Such a case may easily happen if the manifest is filtered such that only one of the
switch adaptation sets will be present in the manifest.

PiperOrigin-RevId: 229365379

PiperOrigin-RevId: 229365333

PiperOrigin-RevId: 229364563

The buffered position is currently based on the mimimum queued timestamp of
all AV tracks. If the tracks have unequal lengths, one track continues loading
without bounds as the "buffered position" will always stay at the shorter
track's duration.

This change adds an optional buffer flag to mark the last sample of the
stream. This is set in the Mp4Extractor only so far. ExtractorMediaSource
uses this flag to ignore AV streams in the buffered duration calculation if
they already finished loading.

Issue:#3670
PiperOrigin-RevId: 229359899

Issue: #5378
PiperOrigin-RevId: 229261658

We currently forget whether a source is seekable at re-preparation. This was
implemented intentionally this way under the assumption that we really can't seek
until we have loaded the seek map again. However, seek operations are only
allowed after a media period is prepared. So there is no harm in remembering
whether a source is seekable.

This problem currently prevents reusing ClippingMediaSources with
ExtractorMediaSource and a non-zero start clip position.

Issue: #5351
PiperOrigin-RevId: 229169441