SDK / exoplayer

Issue: #4097

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

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

Also added an assertion to the DRM event dispatcher to cause
immediate failure when this happens. This is consistent with
the assertion in the equivalent MediaSource class.

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

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

Issue: #4075

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

Also refactor the tests to make them behavioral (rather than testing the method)
and inline simple assertions.

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

These don't seem to be needed anymore. All tests run without them in gradle
and Blaze.

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

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

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

In MatroskaExtractor TrueHD audio samples are joined into larger chunks. For
some streams the resulting chunked samples seem never to start with a syncframe.
This could result in playback of TrueHD streams getting stuck after seeking
because we could never read a syncframe at the start of a sample to determine
the sample size.

Instead of expecting to find a syncframe at the start of a sample, search for it
within the sample, to fix this issue.

Note: this means that we may search a few thousand bytes to find the sample
size, but the cost is only incurred for the first audio sample read.

Issue: #3845

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

Also increase the chunking size to sixteen samples.

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

This field (formerly "id") is almost impossible to use so far. Having setters
in the factories allows to specify custom tags for all media sources.

Also added a ExoPlayer.getCurrentTag() method to retrieve the tag of the
currently playing media source in a convenient way.

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

The data collector keeps track of active media periods to assign each event to
the correct media period and/or window. This information, together with other
information like playback position and buffered duration, is then forwarded
with the event to all registered listeners.

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

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

Issue: #4084

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

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

Previously the SonicAudioProcessor and SilenceSkippingAudioProcessor would track
their pending playback parameters and only apply them in flush(). Having the
values only take effect once flushed made the processors a bit more difficult to
use, especially because the value returned by isActive wouldn't update
immediately.

Make DefaultAudioSink only set the new speed/pitch/skip silence setting after
the audio processors have drained. This means it's no longer necessary to keep
track of pending parameter values and also fixes a bug where initial playback
parameters weren't applied because the audio processors weren't flushed while
uninitialized before DefaultAudioSink called isActive() on them.

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

The previous API allowed to pass in null to the constructors although variants
without listeners exist. That's why we need to handle these null values.

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

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

Partial rollback of [] which caused b/77294898 by deleting a public Exoplayer API.

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

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

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