SDK / exoplayer

PiperOrigin-RevId: 254372134

Reads from a SampleQueue, associating each read format with a
DrmSession, if needed.

PiperOrigin-RevId: 254192562

PiperOrigin-RevId: 254187403

PiperOrigin-RevId: 254182080

PiperOrigin-RevId: 254172906

PiperOrigin-RevId: 254156143

PiperOrigin-RevId: 254048233

PiperOrigin-RevId: 254046126

Builds now fail when raw generics are used.

PiperOrigin-RevId: 253969682

PiperOrigin-RevId: 253959976

ISSUE: #6041
PiperOrigin-RevId: 253958225

More information (LSC)
https://docs.google.com/document/d/16tpK6aXqN68PvTyvt4siM-m7f0NXi_8xEeitLDzr8xY/edit?usp=sharing

Tested:
    tap_presubmit: http://test/OCL:253818309:BASE:253788332:1560879553629:9dc07a48
    Some tests failed; test failures are believed to be unrelated to this CL
PiperOrigin-RevId: 253858263

PiperOrigin-RevId: 253808562

We are currently queuing periods in a way such that the new start position
lines up with the end of the previous period (to ensure continuous playback).
However, if the start position of the new period is larger than the total of
all previously played period durations, we may end up with negative renderer
timestamps when seeking back to the beginning of this new period. Negative
timestamps should be avoided as most decoders have problems handling them
correctly.

This change forces a renderer reset if we detect such a seek to a negative
renderer time and also resets the renderer offset to 0 every time all
renderers are disabled, as this is the only time where we can savely change
the offset of an existing media period.

Also, if playback starts with an ad, we choose the content position as
renderer offset to prevent the whole issue from occurring for the seek-behind-
midroll case.

Issue:#6009
Issue:#5323
PiperOrigin-RevId: 253790054

Issue: #6031
PiperOrigin-RevId: 253784986

Issue:#6006
PiperOrigin-RevId: 253781533

In some edge cases the renderer position may be slightly ahead of the
buffered position and the total buffered duration is thus negative. We already
filter that in ExoPlayerImpl for the publicly accessible value. However, we
forward the unfiltered value to other components like the LoadControl, which
may be confusing.

Issue:#6015
PiperOrigin-RevId: 253780460

PiperOrigin-RevId: 253762488

This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.

Support this use case by gracefully catching the exception in the relevant
places.

Issue:#6019
PiperOrigin-RevId: 253759332

Avoids nullable DrmSessionManagers and simplifies sample reading.
To be used as default value for MediaSources.

PiperOrigin-RevId: 253624465

Makes it throwable from SampleStream.maybeThrowError

PiperOrigin-RevId: 253600396

PiperOrigin-RevId: 253593267

Details in
go/ima-mrc-continuous-play

Corresponding js webcore changes is in <unknown commit>.

NoExternal

PiperOrigin-RevId: 253585186

Objects was added in API 19.

PiperOrigin-RevId: 253567490

These are mostly nullability issues.

PiperOrigin-RevId: 253537068

PiperOrigin-RevId: 253228214

PiperOrigin-RevId: 253006112

PiperOrigin-RevId: 252127811

We currently report MediaCodec exceptions as unexpected exceptions instead of
as renderer error. All such exceptions are now wrapped in a new DecoderException
to allow adding more details to the exception.

PiperOrigin-RevId: 252054486

PiperOrigin-RevId: 251961318

PiperOrigin-RevId: 251915459

PiperOrigin-RevId: 251748542

PiperOrigin-RevId: 251748542

It's only thrown in an edge case on API level 20 and below. If it
is thrown it causes playback failure when playback could succeed,
by throwing up through configureCodec.

It seems better just to catch the exception and have the codec be
configured using the format's own width and height.

PiperOrigin-RevId: 251745539

PiperOrigin-RevId: 251617354

Issue:#5955
PiperOrigin-RevId: 251616118