SDK / exoplayer

Postrolls would be skipped because the period duration wasn't know at
the moment of resuming playback after backgrounding, so the position
wouldn't be resolved to resume the postroll ad.

We have the period duration stored in the AdPlaybackState, so we can
use that directly.

Issue: #7518
PiperOrigin-RevId: 317830418

PiperOrigin-RevId: 317672619

The compat dependency is no longer maintained and we need to keep
it at its old version.

PiperOrigin-RevId: 317658349

PiperOrigin-RevId: 317637058

PiperOrigin-RevId: 317636681

The IMA SDK now preloads postrolls which is great as we no longer need
to rely on detecting buffering at the end of the stream to trigger
playing postrolls.

Add in the required logic to detect the period transition to playing
the postroll.

Issue: #7518
PiperOrigin-RevId: 317610682

PiperOrigin-RevId: 317609986

We currently get float ad cue points from IMA, but store these as
longs in microseconds. The cast from double to long would take the
floor of the value, which could lead to stored ad cue points being
off-by-one. Use Math.round to avoid this.

ImaAdsLoader also has code to map a double AdPodInfo position (which
should match a cue point) onto the corresponding ad group index by
searching the long ad cue points. Match the calculation used where we
map float cue points, including narrowing the position to a float
first to avoid regressions if IMA SDK behavior changes to represent
positions in more than float precision later, and also remove the
requirement that the ad positions match exactly as a defensive
measure.

PiperOrigin-RevId: 317607017

PiperOrigin-RevId: 317604812

They currently fall back to the main Looper if the current thread
doesn't have a Looper. All the changed Handlers are guaranteed to
be created on a thread with a Looper (mostly the ExoPlayer playback
Looper) and thus can make this stricter assumption. This makes it
easier to reason about the code as there are no ambiguities as to which
thread the Handler is running on.

PiperOrigin-RevId: 317334503

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/6ae472243f16d1f075328a779f3d4b46e180b76d

*** Original commit ***

PiperOrigin-RevId: 317331407

PiperOrigin-RevId: 317322247

The setForeground mode method blocks in the same way as release
and should use the same timeout if configured.

In case the method runs into the timeout, a player error is reported.

PiperOrigin-RevId: 317283808

*** Original commit ***

Rename Util methods to clarify which Looper is used.

The method name didn't clarify that either the main or current
Looper is used.

***

PiperOrigin-RevId: 317283606

The method name didn't clarify that either the main or current
Looper is used.

PiperOrigin-RevId: 317276561

- It seems conceptually simpler for DefaultExtractorsFactory
- It seems unlikely we'll need to diverge the two. In the case of
  workaround flags we can just have them be no-ops in the version
  that doesn't need them.

PiperOrigin-RevId: 317151955

PiperOrigin-RevId: 317148010

The details are available on the public fields, which are referenced with @see

PiperOrigin-RevId: 317092269

Looks like this change was introduced in
<unknown commit>

onKeysRemoved is currently not triggered in DefaultDrmSessionManager
as far as I can tell. It seems like it should be called from here.

PiperOrigin-RevId: 317072794

It seems more natural given we always end up instantiating a Matroska extractor,
not one that's specific to the WebM subset of Matroska. There's also no reason
not to support Matroska MIME types in DASH.

PiperOrigin-RevId: 316975451

PiperOrigin-RevId: 316949571

*** Original commit ***

Rollforward of commit 5612ac50.

*** Reason for rollforward ***

Rollforward after making sure the handler is created
from the playback thread and not from an app thread.

*** Original change description ***

Rollback of https://github.com/google/ExoPlayer/commit/e1beb1d1946bb8ca94f62578aee8cbadd97b6e2b

*** Original commit ***

Expose experimental offload scheduling

Add a new scheduling mode that stops ExoPlayer main loop
when the audio offload buffer is full and resume it...

***

PiperOrigin-RevId: 316914147

PiperOrigin-RevId: 316902430

PiperOrigin-RevId: 316900193

*** Reason for rollforward ***

Rollforward after making sure the handler is created
from the playback thread and not from an app thread.

*** Original change description ***

Rollback of https://github.com/google/ExoPlayer/commit/e1beb1d1946bb8ca94f62578aee8cbadd97b6e2b

*** Original commit ***

Expose experimental offload scheduling

Add a new scheduling mode that stops ExoPlayer main loop
when the audio offload buffer is full and resume it when
it has been partially played.

This mode needs to be enabled and dissabled manually by the app
for now.

#exo-offload

***

***

PiperOrigin-RevId: 316898804

After an ad pod coming up has preloaded, if the user seeks before it
plays we get pauseAd/stopAd called for that ad pod. Also, the ad will
not load again. Work around this unexpected behavior by handling
pauseAd/stopAd and discarding the ad.

In future, it's likely that the IMA SDK will stop calling those
methods, and will loadAd again for the preloaded ad that was
unexpectedly discarded. This change should be compatible with that,
because the ad won't be discarded any more due to not calling stopAd.

Issue: #7492
PiperOrigin-RevId: 316873699

Ads can appear due to asynchronous ad tag requests completing after
earlier ads in a pod have loaded, so remove the requirement that the
ad count can't change. The MediaPeriodQueue should handling discarding
buffered content if an ad appears before already buffered content, so
I think this case is actually handled correctly by the core player
already.

Also remove the requirement that an ad URI can't change. This is a
defensive measure for now, but it's likely that a later fix in the IMA
SDK for an issue where loadAd is not called after preloading then
seeking before a preloaded ad plays will result in loadAd being called
more than once, and I think it's possible that the second call to
loadAd may have a different URI. Because the ad URI should only change
after an intermediate seek to another MediaPeriod, there shouldn't be
any problems with buffered data not getting discarded.

Issue: #7477
PiperOrigin-RevId: 316871371

The test was trying to synchronize a background decoding thread by
waiting for pending decode calls. However, the background thread needs
to fully queue the newly available output buffer before we can stop
waiting to ensure it's actually fully predictable. So we change the
pending wait to wait until the input buffer is cleared, which only
happens after the decoder is definitely done with it.

Also properly clean-up decoder (including shutting down the background
thread).

PiperOrigin-RevId: 316870659

The release() method was added in the recent IMA API changes for
preloading and now 'collides' with the ExoPlayer AdsLoader release
method. This led to all ads completing being treated as a call to
completely release the ads loader, which meant that the ad playback
state was not updated on resuming after all ads had completed, which
in turn led to playback getting stuck buffering on returning from the
background after all ads played.

Move the IMA callbacks into an inner class to avoid this.

Issue: #7508
PiperOrigin-RevId: 316834561

constructor to note that the builder does NOT
infer the http method from the existence of the
post body.

PiperOrigin-RevId: 316765677

- Leaving the TODO, since there are still MIME types we're unsure about.
- Removing AAC because xHE-AAC does not have this property. We may re-add
  it with an additional profile check to exclude xHE-AAC in the future.

PiperOrigin-RevId: 316715147

We haven't seen it used anywhere in practice. It's a niche feature not
supported by any other extractors, and is one of the very few things
stopping us from simplifying MediaSource implementations to not set the
decodeOnly sample flag. This is a simplification that we want to make,
since the current mechanism doesn't work properly for cases where a
downstream decoder adjusts the buffer presentation timestamps so that
they're different on the output side than on the input side.

PiperOrigin-RevId: 316712302

To be the abstraction to use for integrating with MediaParser.

PiperOrigin-RevId: 316710421

This flag isn't needed anymore because the waiting for keys happens on
the source side and the source just returns NOTHING_READ under the
same conditions.

PiperOrigin-RevId: 316704214

We started using this method from other tests unrelated to
TestExoPlayer, so the method is better placed inside a generic Util
class.

PiperOrigin-RevId: 316675067

PiperOrigin-RevId: 316650017

This change adds MediaSource.getMediaItem and deprecates MediaSource.getTag. For backwards compatibility, the tag is made available through the Window with `mediaItem.playbackProperties.tag` as well as in the deprecated `tag` attribute.

PiperOrigin-RevId: 316539752

We're then able to use this same helper class from tests, to avoid
running into spurious failures caused by long microseconds being
round-tripped through float seconds.

PiperOrigin-RevId: 316435084

Using the default offset as a magic constant makes tests hard to
understand. Improve that by looking up the value from the timeline or
setting it explicitly in multiple places, so the relationship becomes
clear.

PiperOrigin-RevId: 316421977

PiperOrigin-RevId: 316172860