SDK / exoplayer

Issue: #8067
PiperOrigin-RevId: 337122011

The 'implementation' dependency causes problems when resolving
ListenableFuture in contexts that also include the
com.google.guava:listenablefuture:1.0 dependency.

Issue: #7905
Issue: #7997
Issue: #7993
PiperOrigin-RevId: 337093024

Issue: #7961
PiperOrigin-RevId: 337069152

This will reduce the amount of boilerplate required to pass the configuration
values around (especially in a planned future change when logic is factored out
of ImaAdsLoader).

PiperOrigin-RevId: 337058355

This is in preparation for supporting playlists of ads media sources using
ImaAdsLoader.

Existing ways of passing ad tags should still function but are deprecated (and
won't be supported with playlists).

Issue: #3750
PiperOrigin-RevId: 335618364

This change was meant to be in https://github.com/google/ExoPlayer/commit/2e5f2f12adda1b71b9520bf7b2b0a755f41d6cbd but
was not added my mistake.

PiperOrigin-RevId: 337041686

Issue: #8044
PiperOrigin-RevId: 336955479

PiperOrigin-RevId: 336875300

1. The first time the player controls are are made visible,
   there is no animation.
2. The first time the player controls are made visible, the
   "select tracks" button isn't displayed. When tapping to
   subsequently hide the player controls, the button briefly
   becomes visible and then is hidden again. This bug is due
   to state in StyledPlayerControlViewLayoutManager being
   out of sync, resulting in StyledPlayerControlView's
   onVisibilityChange not being called properly.

After this change both of these issues should be resolved.

PiperOrigin-RevId: 336704031

This should fix gradle errors like: "warn: removing resource
com.google.android.exoplayer2.demo:string/exo_controls_fastforward_by_amount_description
without required default value."

PiperOrigin-RevId: 336670827

We stopped using using this MIME type in
https://github.com/google/ExoPlayer/commit/74a9d8f680995f2096c59fde6cd1ef6e85bb4d55

This broke subtitle decoding in some cases (Issue: #7985), which I
fixed in
https://github.com/google/ExoPlayer/commit/7b8895d655c9b48e042f66045bc9c7ab27e93346.

After some discussion we've decided SubtitleDecoderFactory shouldn't
depend on Format.containerMimeType (since the samples have already been
extracted by this point, so the container shouldn't matter). So this
change fixes DashManifestParser to use MimeTypes.APPLICATION_MP4VTT (and
reverts the no-longer-needed SubtitleDecoderFactory change).

PiperOrigin-RevId: 336668450

PiperOrigin-RevId: 336643621

Adjusted the bottom layout of StyledPlayerControlView :
- Enlarged bottom button's height to make tapping easier.
- Extended greyed background area to upper edge of seekbar.
- Gave padding between bottom edge of the overall layout and bottom buttons.
- Reduced horizontal margins between bottom buttons.

PiperOrigin-RevId: 336041160

Issue: #8024
PiperOrigin-RevId: 335846035

The bug affects playlists that start with an I-FRAME only variant.

Issue: #8025
PiperOrigin-RevId: 335819497

PiperOrigin-RevId: 335642909

Issue: #8005
PiperOrigin-RevId: 335625992

Context: Issue: #7988
PiperOrigin-RevId: 335608610

Issue: #7944
PiperOrigin-RevId: 335012643

`subtitle` is only guaranteed to be non-null if
`nextSubtitleEventIndex != C.INDEX_UNSET`. The null check added in
https://github.com/google/ExoPlayer/commit/0efec5f6c12a5d583f24c122fbcbc1b1eebbabc3
was too early.

Issue: #8017
PiperOrigin-RevId: 334777742

This was broken by https://github.com/google/ExoPlayer/commit/74a9d8f680995f2096c59fde6cd1ef6e85bb4d55
because DashManifestParser switched to setting Format.sampleMimeType to
text/vtt while SubtitleDecoderFactory was still expecting
application/x-mp4-vtt. This change teaches SubtitleDecoderFactory to
check both Format.containerMimeType and Format.sampleMimeType.

I'll investigate a follow-up change to remove
MimeTypes.APPLICATION_MP4VTT completely (it's currently still used in
AtomParsers).

Issue: #7985
PiperOrigin-RevId: 334771672

This holds shared test infrastructure that needs to depend on
Robolectric.

PiperOrigin-RevId: 334604041

When I moved ParsableByteArray#data behind a getter I replaced some
assignments with calls to reset(byte[]):
https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd

reset(byte[]) deliberately sets `limit` to `data.length`, in order to
handle cases that were reassigning `data` but not updating `limit`.
However OggPacket was already using `limit` to track where to write
'new' data into the array, so changing `limit` to `data.length` caused
us to try and write new data beyond the end of the array.

I looked at other uses of reset(byte[]) in https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd
and condluded the only other usage in MatroskaExtractor is legit and
shouldn't be updated like this (because MatroskaExtractor previously
*wasn't* correctly updating/maintaining `limit`).

Issue: #7992
PiperOrigin-RevId: 334601586

PiperOrigin-RevId: 334567234

PiperOrigin-RevId: 334562209

Non-realtime AudioTrack playback speed was not taken into account when
extrapolating the old mode's position, causing the position not to
advance smoothly.

This should be a no-op when not using AudioTrack playback params for
speed adjustment.

Issue: #7982
PiperOrigin-RevId: 334151163

Every other subtitleButton has an if not null check, but does not force non null.

Issue: #7962
PiperOrigin-RevId: 334124323

On receiving a fetch error for an ad that would otherwise play based on an
initial/seek position, the pending content position wasn't cleared which meant
that position reporting was broken after a fetch error. Fix this by always
clearing the pending position (if there was a pending position that will have
triggered the fetch error).

Also deduplicate the code for handling empty ad groups (fetch errors)
and ad group load errors.

Issue: #7956
PiperOrigin-RevId: 334113131

PiperOrigin-RevId: 333751261

Issue: #7949
PiperOrigin-RevId: 333733615

ISSUE: #7977
PiperOrigin-RevId: 333726625

PiperOrigin-RevId: 333712782

Issue: #7967
PiperOrigin-RevId: 333709003

Fix bug to place the negative sign in the beginning
of the returned String.

PiperOrigin-RevId: 333504868

PiperOrigin-RevId: 333485323

PiperOrigin-RevId: 333480727

This issue has been observed on a test app stress
testing setEndOfStream.

The issue has not been observed on ExoPlayer,
probably due to timing differences, but it is fixed
preventively.

#exo-offload

PiperOrigin-RevId: 333472136

This seems to be an exact copy of sample.adts. Update the test to use
the same sample but just output to a different dump file.

PiperOrigin-RevId: 333469714

These are from https://medium.com/google-exoplayer/improved-japanese-subtitle-support-7598fee12cf4

PiperOrigin-RevId: 333296789

PiperOrigin-RevId: 333272292