SDK / exoplayer

*** Reason for rollforward ***

Rollforward after making sure the handler is created,
and that a test is written preventing a
similar regression.

*** Original change description ***

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

*** 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 ***

PiperOrigin-RevId: 318274400

PiperOrigin-RevId: 318264209

PiperOrigin-RevId: 318255509

Ignore two tests in AsynchronousMediaCodecBufferEnqueuerTest
until the ShadowMediaCodec's behavior is updated to apply
input buffer ownership.

PiperOrigin-RevId: 318251859

PiperOrigin-RevId: 318152038

This uses a license server implemented using MockWebServer to test
DefaultDrmSessionManager and DefaultDrmSession.

PiperOrigin-RevId: 318086890

PiperOrigin-RevId: 318077821

PiperOrigin-RevId: 318046646

The existing code moves a multi-line cue box by multiples of the height
of the whole cue box (incorrect), rather than multiples of the first
line of text (correct). These two are equivalent for single-line cues,
which is why I didn't initially spot the problem.

PiperOrigin-RevId: 318036793

Numerical lines conceptually map to a grid of lines in the viewport,
with the Cue text lines being aligned to one of the viewport lines.

It doesn't make sense to position a single-line cue differently based
on lineAnchor when it's expected to 'snap' to a particular line on the
viewport grid. So we redefine the position to be in terms of the cue
lines rather than the bounds of the cue box.

It's also not possible to always handle ANCHOR_TYPE_MIDDLE when
lineType=NUMBER (as it relies on the number of lines in the cue being
odd), so it's easier to ignore lineAnchor completely.
PiperOrigin-RevId: 318034664

This removes a lot of duplication from the module configuration,
avoids divergence, and makes sure that only the important differences
to the default are visible in each module file.

PiperOrigin-RevId: 318024823

PiperOrigin-RevId: 317921368

Which is an HlsMediaChunkExtractor based on MediaParser.

PiperOrigin-RevId: 317886412

PiperOrigin-RevId: 317864048

The class was only non-final to allow mocking. Using the real class
in the test works equally well.

PiperOrigin-RevId: 317858805

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