SDK / exoplayer

PiperOrigin-RevId: 290629644

If an exception is thrown between updating the timeline and updating
the position in playbackInfo, the state may be inconsistent.
Exceptions are expected to be thrown while updating the player state
and we should handle such cases in a consistent way.

Similar to how we handle the same situation in seekToInternal,
the state is updated in a final block such that it gets updated to the
latest state even if an error occurs. Moving both the timeline and
position update together also ensures they always stay consistent.

PiperOrigin-RevId: 290624020

This restructure moves all the position resolving code to a static method and
removes the dependency of the MediaPeriodQueue on having an up-to-date timeline.

Both steps allow simplified reasoning about the code as the static method can't change
the state of the player, and there is no risk the queue can use the wrong timeline.

These propoerties allow to fix a bug causing inconsistent states in a follow-up step.

PiperOrigin-RevId: 290616395

Allows items to be added to the queue once the sample stream has already been created.
Means tests can simulate data not all being available at the start.

PiperOrigin-RevId: 290613392

Also de-dupe a couple of case statements

PiperOrigin-RevId: 290610993

PiperOrigin-RevId: 290610936

PiperOrigin-RevId: 290610312

It's never assigned or accessed from outside the class.

It was added in
<unknown commit>
then the accessor was removed in
<unknown commit>

PiperOrigin-RevId: 290601998

PiperOrigin-RevId: 290600248

This makes MPEG audio utilities similar to utilities we have for WAV,
AC-3 etc., and moves them out of the extractor package so that an
extractor module can be split out without needing to have a class in the
extractor package in the common library.

PiperOrigin-RevId: 290595089

All these genres are currently causing a warning and are not added to the Metadata.Entry.

PiperOrigin-RevId: 290594810

*** Original commit ***

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

*** Original commit ***

Fix some logic in AnalyticsCollector.

All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is...

***

PiperOrigin-RevId: 290593700

+ force arm (over thumb) mode for 32-bit builds

-O2 improves performance ~30-40% over the default -Oz depending on the
resolution; this is similar to what is done for vp9 which uses -O3.

PiperOrigin-RevId: 290318121

*** Original commit ***

Fix some logic in AnalyticsCollector.

All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is empty or a seek is pending. Since adding all the playlist API methods to the player,
this is no longer the right choice. Moreover,...

***

PiperOrigin-RevId: 290312118

Currently both are updated by separate setters. If an exception is thrown between
the two setters, the state may not be consistent.

Avoid this problem by always setting them together.

PiperOrigin-RevId: 290293600

All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is empty or a seek is pending. Since adding all the playlist API methods to the player,
this is no longer the right choice. Moreover, we don't have a definite API that tells
AnalyticsCollector when a playlist API call has been handled (and we don't want to
have one).

We can fix this by always using the current Player position information as the source
of truth (instead of the media period queue). This is definitely more correct and also
works while a masking operation is pending. To fill in the additional information from
the media period queue, we can look up a matching media period. This may not be the
first one in the list if an operation is pending.

The new methods are similar to the previous tryResolveWindowIndex method, but:
 1. They are always used (i.e. the current Player state is the main source of truth)
 2. They also check the correct ad playback state, that was just ignored previously.

PiperOrigin-RevId: 290284916

PiperOrigin-RevId: 290276507

Currently seeks are basically ignored. However, it's more realistic to re-queue the
single sample if the seek is to position 0.

PiperOrigin-RevId: 290273564

*** Original commit ***

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

*** Original commit ***

Move getting-stuck-prevention into DefaultLoadControl.

We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (https://github.com/google/ExoPlayer/commit/b84bde025258e7307c52eaf6bbe58157d788aa06).

Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a...

***

PiperOrigin-RevId: 290273295

- Add additional Listener methods to DownloadManager, to inform of
  changes to whether the downloads are paused or waiting for requirements.

- Only schedule the Scheduler if we really are waiting for requirements.

- Only restart the service if we're no longer waiting for requirements,
  and if there are queued downloads that will now be restarted.
  Previously the service would be restarted whenever the requirements
  were met, regardless of whether there was any work to do.

- Restart service if it might be stopping, as well as if it's already
  stopped. Also restart service if there's a download state change to a
  state for which the service should be started, if.

Issue: #6798
PiperOrigin-RevId: 290270547

First cl towards DefaultMediaSourceFactory (<unknown commit>) does not change the MediaSourceFactory interface except adding @Nullable anotations to setters.

PiperOrigin-RevId: 290269640

PiperOrigin-RevId: 290269098

Doing so prevent Codec which is a big object with
JNI to be garbage collected.

As the codec can not be hold in the listener, there
is no way to call release, as it must be called on
the same codec.
As a result the release method is also removed.
The downside is that at runtime some callbacks may be
dropped but it should be a short transitive state.

This also simplifies lifecycle of the listener as
the client does not have to know if release needs
to be called or not.

An alternative would have been to hold a weak ref,
but I deemed it too complicated for the
runtime gain.

PiperOrigin-RevId: 290231659

Issue: #6155
PiperOrigin-RevId: 290117324

PiperOrigin-RevId: 290079840

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