SDK / exoplayer

Previously it was necessary to create a new Sonic instance every time the
processor was flushed. Add a flush() method to Sonic so that it can be reused
when seeking. It still needs to be recreated when parameters change.

SonicAudioProcessor and SilenceSkippingAudioProcessor have methods for setting
parameters that are documented as taking effect after a call to flush(), but
actually the value returned by isActive() was updated immediately. Track the
pending values and apply them in flush() to fix this.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191442336

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191422866

- Upgrade to latest version
- Use api dependency, since application code that uses the
  extension more has to use OkHttp directly to make an
  OkHttpClient instance
- Add proguard configuration

Issue #4059

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191422594

We currently refresh repeatedly in this case. According to the
DASH spec omitting minUpdatePeriod indicates that the manifest
does not change, and therefore we should not refresh. I think
it might be valid to omit minUpdatePeriod in a dynamic manifest
if relying exclusively on EMSGs to trigger manifest refresh.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191420247

Issue #4059

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191419955

applyContentMetadataMutations and getContentMetadata methods suppossed to be synchronized and assert the instance isn't released.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191419637

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191418665

Issue: #4059

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191414566

This is in preparation for making it possible to flush a Sonic instance so that
it's not necessary to create new ones every time the processor is flushed.

There should be no behavior changes here.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191410326

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191409777

Issue: #3723

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191407560

To be immediately rolled back after submission

Submitting on behalf of cblay.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=191128111

- Fix typo
- Reinstate copy step. It's needed for images

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190976774

- Remove stray extra "/" from postprocessed oracle URLs
- Remove date lines so the Javadoc diff better shows what
  actually changed between releases

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190973079

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190942033

Weirdly, the Android Javadoc indicates that it returns something
before the API level on which the same Javadoc states it was added.
In any case, we can simply not call the method to avoid the
warning, since we only use the value if the API level is at least
23 anyway.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190941776

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190941619

Video renderers assume that the player position is advancing linearly while in
the started state. MediaCodecVideoRenderer schedules frames for rendering in the
future in the expectation that the player position is advancing.

This assumption is not currently true when using a position from the AudioTrack:
the player position can be fixed for (in the worst case) up to about 100 ms
before it starts increasing. This leads to an effect where the first frame is
rendered then a few other frames are rendered, then there's a pause before
frames start being rendered smoothly.

Work around this issue by checking whether the position has started advancing
before scheduling frames to be rendered in the future.

It might be preferable to make the audio renderer only become ready when its
timestamp can start advancing, but this is likely to be complicated.

Issue: #3841

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190937429

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190927811

Issue: #3729

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190922866

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190917894

In audio processors an audio frame consists of a sample (which is 2 bytes for
16-bit PCM) for each channel. Sonic used "sample" to refer to this.

We've already diverged from the original source for Sonic quite a bit (deleting
code and making stylistic changes) and there haven't been upstream changes so
far, so it seems fine to start making more substantial changes here.

There should be no behavior changes here.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190916793

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190916130

Use string concatenation for Metadata.Entry instances, and add
Util.formatInvariant for numerical formatting.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190915643

This adds two options to the ClippingMediaSource which allow proper clipping
of live streams:
 1. The clipping stays fixed relative to already created media periods. That
    means that playback actually progresses through the clipped media and
    eventually reaches the end of the clipping. The window is also marked
    as non-dynamic to let playback end in this case.
 2. Allow to specify a clipping duration relative to the default position to
    be able to specify the duration of live stream which is to be played.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190911049

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190907004

*** Reason for rollback ***

b/76391022 was caused by a timestamp correction in StabilizableSimpleExoPlayer which will be fixed with this CL.

*** Original change description ***

Automated g4 rollback of changelist 189570277.

*** Reason for rollback ***

causes b/76391022, motion still playback in Photos is broken

*** Original change description ***

Used fixed time frame in clipping media period.

Currently, whenever the clipping is updated, we move the time frame of the
clipped period to start at 0. This causes problems when we are already playing
this period and the renderer position does no longer match the stream
positions.

This change keeps the time frame of the...

***

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190906020

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190896757

- Ensure that no memory is used by audio processors that are always inactive, by
  only allocating in flush() if active. If data was already allocated but a
  processor becomes inactive we assume that the allocation may be needed in
  future so do not remove it (e.g., in the case of ResamplingAudioProcessor).
- Make SilenceSkippingAudioProcessor set up its buffers in flush(), and clarify
  that it is always necessary to call flush() if configure() returns true.
- Make reset() reset all state for all processors.
- Use @Nullable state or empty arrays for inactive audio processor buffers.
- Miscellaneous style/consistency cleanup.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190895783

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190817805

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190787979

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190787884

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190782395

A merge error in a previous change removed the drmSessionManager from
the player factory call.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190769364

In some situations, the timeline can't be specified because it is created
internally by the media source under test. If the test still needs to wait for
a timeline update, this change allows to do that by specifying an expected
timeline of null.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190768386

Doing that in the current order may result in cases where we have a player
instance but a null media source and thus the next call to initializePlayer
will fail.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190765633

Issue: #3514

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190752950

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190751660

This uses a simple threshold-based algorithm for classifying audio frames as
silent, and removes silences from input audio that last longer than a given
duration.

The plan is to expose this functionality via PlaybackParameters in a later
change.

Issue: #2635

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190737027

They don't really belong there; it was basically a convenience
thing where one of the arguments to the track selector was being
packaged up in the result to avoid having to hold a separate
reference to it.

This change is being made as a precursor to a subsequent change
where creating the TrackSelectorResult will move from
MappingTrackSelector to DefaultTrackSelector. DefaultTrackSelector
doesn't currently have access to the un-mapped tracks, and so is
unable to create a TrackSelectorResult. It's IMO preferable to
keep it that way rather than passing them down just so they can
be included in the result.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=190640594