SDK / exoplayer

If a source is removed from the playlist, the player may still call createPeriod
for a period of the removed source as long as the new timeline hasn't been handled
by the player. These events are stale and can be ignored by using a dummy media
source. The stale media period will be released when the player handles the updated
timeline.

Issue:#4871

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

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

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

Issue: #4834

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

Issue: #4857

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

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

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

This method needs to be called whenever the track selection of the current
loading period changes, but also when the loading period itself (and thus
the "loading track selection") changes. These are the same situations in which
we update the loading media period id and thus we can move both updates in
a common helper method.

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

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

From API 23 this uses the timed format queue. Before API 23 the
format is notified as soon as the buffer is queued.

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

Before this change we would reset the start trim to zero after initial
configuration (at the start of playback) and after seeking to any position. The
fact that no trimming was applied at the start of playback meant that after the
first period transition we'd see a mismatch between the next buffer timestamp
(equal to the duration of the period taking into account edits) and the duration
of audio submitted to the sink.

This change modifies the behavior so that we reset the start trim to zero only
if some audio was queued since configuration. This is incorrect in the case of
starting playback at a non-zero position, but fixes the common case of starting
at zero. As before, a later seek to any position is handled via a flush and
resets the trim as required.

Transitions from one period to the next are unaffected by this change.

One way to implement start trimming correctly would be to provide the input
buffer timestamp to the audio processors and only trim when handling audio from
the start of the stream, but that is a larger change so left for later.

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

Also fix internal build by adding some methods.

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

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

After a period transition the first buffer queued has the sum of previous period
durations added to its source presentation timestamp. These durations take into
account gapless edits, but the check on the timestamp was based on the submitted
frame count, not the frame count after trimming.

This change fixes an issue where audio/video would gradually drift apart due to
accumulated error in the audio track position, which could lead to freezing due
to the audio renderer stopping being ready and switching to the standalone media
clock.

Issue: #4559

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

Trackselector filter on framerate

Fixed and random track selection were still overriding the deprecated version
of updateSelectedTrack.

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

The only use of track selection factories is as adaptive track selection factories
in the DefaultTrackSelector. Using the fixed track selection factory here is dangerous
as it will throw if more than one track is selected.

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

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

With default of value set to -1, every single dropped frame is reported because of expression: if (droppedFrames >= maxDroppedFramesToNotify) {  maybeNotifyDroppedFrames(); }

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

The decoder doesn't claim to be adaptive, but if we're staying
in the same resolution we'll try and re-use the decoder anyway.
The H264 decoder can't handle this case on the Tab 4 can't deal
with this case.

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

This matches the non-gapless case.

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

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

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

This doesn't break apps which violate this policy. But it creates a clear
warning which is also likely to be reported in analytics tools.

Issue:#4463

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

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

The DefaultTrackSelector can now be constructed without leaving out a
vital part of the initialization. This allows this new simple factory method.

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

This reduces the possiblity of regressions.

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

Currently there is no way to disable (or reduce) the logcat output generated
by ExoPlayer.

Issue:#4665

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

This allows creating multiple HLS media sources from a single Factory, as
required by the interface.

Issue:#4814

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

Issue: #4824

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

ExoPlayer can be run on a background thread, but some components (UI and IMA)
only support players on the main thread. This adds some documentation and
assertions for that.

To simplify assertions, this also moves the getApplicationLooper method from
ExoPlayer to Player.

Issue:#4439

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

Kotlin will throw NPE whenever a method returns null or an interface is
called with a null parameter and the respective values are not marked as
@Nullable.

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

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

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

To check the validity of a window index it needs to be compared with a greater
or equal sign to the window count.

Issue:#4822

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

Also prevent an unnecessary allocation when the removed range is empty.

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

Not having this annotation may cause Kotlin implementations to fail.

Issue:#4802

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

If we can select a track that has a strictly higher score than a
selection already made for a renderer of the same type, we should
prefer it.

Issue: #4711

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