SDK / exoplayer

It could either live in .util or .extractor, but since it's not needed
outside the extractor package in core (and the FLAC extension), and
FlacStreamMetadataTest uses a FLAC asset, it seems preferable to move it
into the extractor package.

PiperOrigin-RevId: 291372032

CeaUtil depends on TrackOutput so should live in the extractors package.

To avoid having Cea708Decoder depend on extractors, this change also
moves the initialization data building/parsing to CodecSpecificDataUtil.

PiperOrigin-RevId: 291348317

PiperOrigin-RevId: 291340508

Using @test(expected=...) is discouraged, since the test will pass if
any statement in the test method throws the expected exception.

PiperOrigin-RevId: 291338224

PiperOrigin-RevId: 291207668

Improve unit tests of binary search methods by making them more
behavior-driven.

PiperOrigin-RevId: 291175304

The deleted path was only used if resetPosition=false and clearPlaylist=true,
which is never the case.

PiperOrigin-RevId: 291154550

Since we have the Playlist layer on top, it's always guaranteed that a
new playlist item has a new uid. So we can just keep the old one in all
cases and don't have to be careful to delete it. The deletion was necessary
previously in case multiple MediaSources use the same uids.

PiperOrigin-RevId: 291152349

Move Cea708InitializationData functionality into CeaUtil and delete the
class.

Move CeaUtil to the util package as it needs to be used both in
extraction and decoding.

PiperOrigin-RevId: 291128220

PiperOrigin-RevId: 291125686

PiperOrigin-RevId: 290934472

Move player messages and scaling modes to Renderer.

Remove @links to ExoPlayer AudioAttributes and renderers.

PiperOrigin-RevId: 290932785

PiperOrigin-RevId: 290910992

Currently we only do this for the main sample URI, not for subtitles.
So pairing a web-based video file with a local subtitle file on a fresh
install just throws a 'permission denied' exception.

PiperOrigin-RevId: 290794091

The only remaining use is to provide the initial position for the first media
period in the queue. At this point, the value is always equivalent to
PlaybackInfo.positionUs because they are set together to the same value in
PlaybackInfo.copyWithNewPosition.

PiperOrigin-RevId: 290749294

We have a flag that gets turned on if the current playback position has been
reset, so that messages from this reset position can be triggered. This
mechanism isn't actually depending on the startPositionUs field because it
should always be triggered in the first iteration with the new position.

PiperOrigin-RevId: 290749201

There are a couple of problems with how positions in PlaybackInfo are set at
the moment:
1. PositionUs isn't allowed to be C.TIME_UNSET. This is prevented by always
resolving to the current default position if needed.
2. In some places a window position was used as a period position. Use correct
position resolution procedure.
3. When creating a placeholder position to restart playback, we used the first
period in a window, not the one where the default position is.
4. The start position for ads was in some cases set to 0 without checking
the ad resume position.

PiperOrigin-RevId: 290749042

Add queueInputBuffer() and queueSecureInputBuffer() in
MediaCodecAdapter.

PiperOrigin-RevId: 290720307

Once EOS has been read, that will be returned every time readData is called.
EOS needs to be an item in the items.

PiperOrigin-RevId: 290715513

PiperOrigin-RevId: 290712014

This avoids keeping a redundant (and potentially out of sync) copy of
the same info in builderLength.

PiperOrigin-RevId: 290709360

I needed to use Cue.Builder instead of just SpannableStringBuilder for
the regionOutput values, so I could attach the vertical info where
appropriate (since this is a property of the Cue, not a span).

PiperOrigin-RevId: 290709294

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