SDK / exoplayer

Issue: Issue: #6978
PiperOrigin-RevId: 318710782

PiperOrigin-RevId: 318485946

According to the discussion in <unknown commit>.

PiperOrigin-RevId: 318473575

On reaching the end of the content we would notify content complete
and skip unplayed ads, causing a timeline change. That timeline change
was handled in a way that caused a further timeline change in the
2.11.6 release, where we don't yet deduplicate no-op Timeline changes,
causing repeated timeline changes indefinitely.

At tip-of-tree, the timeline wouldn't refresh repeatedly. However the
code for sending content complete at the point of transitioning to
play a preloaded postroll ad was not correct in that it didn't mark
previous ads as skipped. Instead they happened to be marked as
skipped later on due to the timeline change handling content
completion code triggering again.

Fix this by only marking ads as skipped when content completes once,
to avoid the duplicate timeline change, and moving the skipped ad
marking so it happens in the same place as notifying content complete.

PiperOrigin-RevId: 318454908

MediaCodec does not need to be re-created in the
event of gapless metadata.

PiperOrigin-RevId: 318439694

Gapless offload is fixed in later R beta builds of all Pixels supporting R.

On the firsts R beta builds of Pixel 4, run the following command.
`setprop vendor.audio.offload.gapless.enabled true`.

It can not be enabled on the first Pixel 2 and 3 beta build.

PiperOrigin-RevId: 318436134

This it is enabled only on a list of
manually tested devices.
The list is empty in this CL.

*** Reason for rollforward ***

Fixed dependent cl was rolled forward.

*** Original change description ***

Rollback of https://github.com/google/ExoPlayer/commit/962e08d3be3b47166d1628cd1951e115c5cc00be

*** Original commit ***

Add Offload gapless support

Confirmed to work on a Pixel 4 after enabling the feature:
 `setprop vendor.audio.offload.gapless.enabled true`

***

***

PiperOrigin-RevId: 318433123

*** Reason for rollforward ***

Fixed dependent cl was rolled forward

*** Original change description ***

Rollback of https://github.com/google/ExoPlayer/commit/2aac0717d728df5511ebac5855467e83cd2d4aa0

*** Original commit ***

Propagate format in supportsOutput

It is needed to know if gapless is needed,
as gapless offload might not be supported.

***

***

PiperOrigin-RevId: 318429321

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