SDK / exoplayer

I don't need to keep a separate playback looper, I can just use
ShadowLooper.idleMainLooper().

PiperOrigin-RevId: 318823190

- Deprecate constructors that don't take an executor, to direct
  developers toward the new ones. Callers can trivially pass
  Runnable::run to one of the new ones if they want old behaviour.
- Add comment explaining warning suppression added in the CL that
  added parallelised download support.

Issue: #5978
PiperOrigin-RevId: 318803296

This will be necessary to support partially fragmented MP4s.

PiperOrigin-RevId: 318798726

This enhances readability, particularly as those methods will become
more complex when partially fragmented media will be supported.

PiperOrigin-RevId: 318795536

PiperOrigin-RevId: 318790917

Previously only pcm encoding were stored in Format,
this was an issue as for audio passthrough and offload
lots of code needs to pass complex format informations
(encoding, sample rate, channel count, gapless metadata)
but could not use Format and each function was taking
each as different parameter.

By allowing Format to contain any encoding, and not only
pcmEncoding, it allows to pass a Format everywhere in ExoPlayer
code that needs a Format.

This patch does not have any functional change. It is only an internal refactor.

PiperOrigin-RevId: 318789444

PiperOrigin-RevId: 318786283

PiperOrigin-RevId: 318785458

The seek start position was set to the first mdat but this box was
always skipped because the moof box was not read.

PiperOrigin-RevId: 318762126

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