SDK / exoplayer

r2.10.7

PiperOrigin-RevId: 278658259

PiperOrigin-RevId: 278332587

PiperOrigin-RevId: 277963928

Which ensures both get updated when the MediaSessionConnector player
changes.

Issue:#6582
PiperOrigin-RevId: 277254889

- This is for consistency with PlayerControlView.

- Also update PlayerNotificationManager notification if shuffle
  mode changes. This is for consistency with what happens when
  the repeat mode changes. By default the notification will be
  unchanged, but custom implementations can extend and then
  override createNotification, and given these modes change
  infrequently it feels like we can just do this. The alternative
  for achieving consistency would be to remove handling of repeat
  mode changes.

Issue: #6582
PiperOrigin-RevId: 277925094

PiperOrigin-RevId: 277910360

E-AC3 with JOC is signaled using the CHANNELS attribute for HLS:
https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices/hls_authoring_specification_for_apple_devices_appendices

PiperOrigin-RevId: 277680300

The framework opus decoder discards some samples after a call to
flush(). Because we flush a decoder that is being retained across an
input format change, this means that the start of audio gets truncated
when transitioning to a new opus stream. See also
https://android.googlesource.com/platform/frameworks/av/+/refs/heads/android10-release/media/libstagefright/codecs/opus/dec/SoftOpus.cpp.

Avoid this by recreating opus decoders instead of flushing them. It
seems fine to do this for all opus decoders as reinitialization should
be cheap, OEM-provided implementations may also discard samples and
playback shouldn't be interrupted on reinitialization due to the
downstream AudioTrack buffer.

PiperOrigin-RevId: 277458759

The leanback library doesn't know about non-square pixels. So if
we're playing content that uses non-square pixels, we need to adjust
the video dimensions that we provide to leanback such that it
renders the video with the correct aspect ratio.

PiperOrigin-RevId: 277042560

Float.MIN_VALUE is very close to zero:

PiperOrigin-RevId: 276674142

PiperOrigin-RevId: 276660235

Without this, a subtitle track empty edit list used to offset the start of
subtitles is ignored.

Also the current code seems to depend on the order in which
we parse the tracks (audio first means we have gapless info when we parse
video track, while video first we wouldn't).

It's not clear why we can't handle both edit lists & gapless info

PiperOrigin-RevId: 276029744

The compositeSequenableLoader was causing NPEs in isLoading. Initializing it
upfront prevents this problem and is in line with what we do in all real
MediaPeriods.

PiperOrigin-RevId: 275491511

r2.10.6

Issue:#6537
PiperOrigin-RevId: 275477266

If an odd resolution is impossible in the specification itself, then we know
that the caller is passing invalid data. Round up on the assumption it's a
rounding error so that playback can proceed.

Issue: #6551
PiperOrigin-RevId: 275226813

Same change as done in https://github.com/google/ExoPlayer/commit/c49388aca2047ed7680e7d8834def4f769060e2d.

PiperOrigin-RevId: 274894288

PiperOrigin-RevId: 274568961

PiperOrigin-RevId: 274568660

PiperOrigin-RevId: 274564800

PiperOrigin-RevId: 274561876

PiperOrigin-RevId: 274534626

Issue: #6523
PiperOrigin-RevId: 274160232

It's documented to be for temporary loss only (i.e. the case where
externally reported playWhenReady is still true)

PiperOrigin-RevId: 274129922

PiperOrigin-RevId: 273971120

This supports both chunkless & traditional preparation

PiperOrigin-RevId: 273938344

Playback cannot be suppressed if playWhenReady=false

PiperOrigin-RevId: 273726084

PiperOrigin-RevId: 273549830

Issue: #6297
PiperOrigin-RevId: 273297284

It's confusing that app:played_color also modifies the colors
that derive from it, but the corresponding setter does not. It
seems generally clearer just to define constants.

PiperOrigin-RevId: 273249557

It's confusing that seekTo(player, windowIndex, positionMs) does
clamping, because it only makes sense if windowIndex is the current
window.

Note: This doesn't actually fix anything (other than code clarity).
In cases where we were passing other windowIndices, we always
passed 0 as the position and so the clamping logic wouldn't have
had any effect.
PiperOrigin-RevId: 272857104

PiperOrigin-RevId: 272856747

These seem to be created by the Android Studio layout inspector

PiperOrigin-RevId: 272856118

Keeping the ones inside loops, because theoretically they
can be useful there (in practice, for this use case, it's
highly unlikely to make any difference).

PiperOrigin-RevId: 272834073

PiperOrigin-RevId: 272654378

Log only if an error occured.

PiperOrigin-RevId: 272618322

PiperOrigin-RevId: 272614917