SDK / exoplayer

This avoids allocating a Runnable.

PiperOrigin-RevId: 290079660

This fixes an issue where a DownloadService implementation
that allows foreground but doesn't provide a scheduler would
not be restarted in the case that it was still in memory but
classed as idle by the platform.

It also speeds up service restart in the case that a
scheduler is provided.

Issue: #6798
PiperOrigin-RevId: 290068960

This method has two use cases:

1. Seeking. Calls are immediately preceded by a call to rewind(), and
   the returned value isn't important unless it's ADVANCED_FAILED (i.e.
   the caller is only interested in success and failure).
2. Advancing. The return value is important unless it's ADVANCED_FAILED,
   in which case the caller wants to treat it as 0.

This change creates separate methods for each use case. The new seekTo
methods automatically rewind and return a boolean. The updated advanceTo
method returns 0 directly in cases where ADVANCED_FAILED was returned.
Arguments that were always hard-coded to true by callers have also been
removed.

This change is a step toward one possible solution for #6155. How we'll
solve that issue is still up for discussion, but this change seems like
one we should make regardless!

Issue: #6155
PiperOrigin-RevId: 290053743

- DownloadManagerHelper now passes all downloads to the
  DownloadService when the service is attached (and once
  the downloads are known). The service then starts the
  foreground notification updater if necessary. This fixes
  the ref'd issue.
- Don't call getScheduler() if the service is background
  only. This was already documented to be the case on the
  DownloadService constructor.
- If the service is started in the foreground on SDK level
  26 and higher, satisfy the condition to move the service
  to the foreground in onStartCommand rather than in stop().
  It's much more obviously correct, and should produce the
  same end result.

Issue: #6798
PiperOrigin-RevId: 290050024

PiperOrigin-RevId: 290041295

Currently the following sequence of events happens at automatic period transitions:
1. Update queue (=release old playing period)
2. Disable unused renderers
3. Enable newly needed renderers

This order requires difficult to follow workarounds in AnalyticsCollector for all
events related to step 2 (disable renderers). The current media period has already
been advanced so can't be used. The current workaround saves the last known playing
media period that was published as part of a PlaybackInfo update in ExoPlayerImpl.
This works in most cases, but is inherently wrong because the published state in
ExoPlayerImpl may be completely unrelated to the updates happening on the playback
thread (e.g. if many other operations are pending).

Simplify and fix this problem by changing the order of the events above:
1. Disable unused renderers.
2. Update queue
3. Enable newly needed renderers.
This way the current playing media period can be used for both renderer disable
and renderer enable events, thus it's correct in all cases and the workaround
in AnalyticsCollector can be removed.

PiperOrigin-RevId: 290037225

Whenever we set the maskingWindowIndex, we also need to set the masking period index
and the masking position. Otherwise it may cause exception when the period index
is used together with the masking timeline.

PiperOrigin-RevId: 290036973

PiperOrigin-RevId: 290032841

PiperOrigin-RevId: 290027772

PiperOrigin-RevId: 289859343

This optimization allows a ChunkSampleStream to output track
formats as soon as they're parsed during an InitializationChunk
load, rather than waiting until after the InitializationChunk
load is completed.

In DASH VOD, a single InitializationChunk typically loads the
moov and sidx atoms in that order. Hence for long form content
where the sidx is a non-trivial size, this may result in the
track formats being output a non-negligible period of time
sooner than was previously the case. This allows downstream
renderers to start codec initialization sooner, potentially
decreasing startup latency.

For a single test stream on a fast & stable network, this
pretty consistently reduced elapsed time until both audio and
video codecs have been initialized from ~0.5s to ~0.3 seconds
on a Galaxy S8. For 5 test runs without and with these patches,
the eventTime logged by EventLogger for the second decoder
init were:

Without (secs): 0.47 0.47 0.45 0.48 0.46
With (secs)   : 0.32 0.33 0.34 0.31 0.40

PiperOrigin-RevId: 289845089

The current order of operations means that the Format is only passed
to the chunk's output after the DataSource has been opened. This
means that establishing the network connection and the downstream
renderers initializing their codecs are effectively serialized to
occur one after the other.

In the new order, the Format is passed to the chunk's output before
the DataSource has been opened. This allows the downstream renderers
to initialize their codecs in parallel with the network connection
being established, and hence latency at the start of playback is
reduced.

PiperOrigin-RevId: 289841854

PiperOrigin-RevId: 289838473

PiperOrigin-RevId: 289829592

PiperOrigin-RevId: 289823804

Issue: #6870
PiperOrigin-RevId: 289658261

PiperOrigin-RevId: 289658098

PiperOrigin-RevId: 289521837

PiperOrigin-RevId: 289494365

PiperOrigin-RevId: 289490708

We currently have a currentMediaPeriodId and an activeSessionId that are more
or less tracking the same thing unless the current media period isn't "active" yet.

Simplify this logic by using a single currentSessionId field and the respective
isActive flag of this session. Also move all session creation and activation code in
the same method to make it easier to reason about the code.

This change also fixes a subtle bug where events after a seek to a new window
are not ignored as they should.

PiperOrigin-RevId: 289432181

Issue: #6798
PiperOrigin-RevId: 289424582

PiperOrigin-RevId: 289424321

As discovered whilst investigating #6798, there are cases
where these methods are not correctly. They were added as
convenience methods that could be overridden by concrete
DownloadService implementations, but since they don't work
properly it's preferable to require application code to
listen to their DownloadManager directly instead.

Notes:

- The original proposal to fix #6798 stored the state change
events in memory until they could be delivered. This approach
is not ideal because the events still end up being delivered
later than they should be. We also want to fix the root cause
in a different way that does not require doing this.
- This change does not fix #6798. It's a preparatory step.

Issue: #6798
PiperOrigin-RevId: 289418555

This change makes it clear the SampleQueue doesn't outlive
the wrapping PlayerTrackEmsgHandler, and releases it from
PlayerTrackEmsgHandler.release().

This change is a no-op because calling release() is the
same as reset() in this case (the behavior only differs if
a non-dummy DrmSessionManager is being used).

PiperOrigin-RevId: 289416622

As a result, onMediaChunkLoadStarted gets invoked on the loading thread, and
init on the playback thread, matching the thread access comments.

Issue:#6321
PiperOrigin-RevId: 289167981

Dash live streams require that the client has an accurate wall clock
time and in absence of a UTCTiming element, this is assumed to be the
NTP time.

This change adds NTP time offset resolution for DASH live streams
without such timing elements.

PiperOrigin-RevId: 289098796

PiperOrigin-RevId: 289092332

I'll use this in TtmlDecoderTest

PiperOrigin-RevId: 289091526

PiperOrigin-RevId: 289091494

Suggested during the review of <unknown commit>

PiperOrigin-RevId: 289088296

PiperOrigin-RevId: 289054937

Unfortunately devices such as the MI 8 do not provide an alternative
working decoder. Some Vivo devices do provide one though.

PiperOrigin-RevId: 288911897

PiperOrigin-RevId: 288886739

Some members are nullable but were not marked as
such.

PiperOrigin-RevId: 288873481

PiperOrigin-RevId: 288868298

Also fix annotation style of the surrounding functions.

PiperOrigin-RevId: 288865420

PiperOrigin-RevId: 288862795

I'm going to use these in TtmlDecoderTest

PiperOrigin-RevId: 288862274

Ultimately we only care if the style is both bold & italic, if some of
those are specified multiple times there's no problem.

PiperOrigin-RevId: 288862235