SDK / exoplayer

Checking the expected next/previous window indices and if the correct window
or period gets returned.

TimelineTest defines mock classes and verification methods used by the specific
implementation tests.

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

Fix unused variable

Issue: #2788

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

When readingPeriodHolder and playingPeriodHolder are both null, a
NullPointerException is thrown when trying to reassign readingPeriodHolder.

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

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

(Relating to GitHub issue #2577)

Changing the repeat mode during playback may require to discard or rebuffer
certain periods because the requested order of playback changed.

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

(Relating to GitHub Issue #2577)

The Timeline base class provides the default implementation.

Timeline wrappers (e.g. ClippingTimeline, ConcatatedTimeline) forward all
requests to the respective inner timelines. Some like ConcatenatedTimeline add
their own additional logic to bridge between the child timelines.

In addition, ConcatenatedTimeline and LoopingTimeline now have a common
abstract base class as they share most of their code.

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

Even though this is not strictly spec compliant, this will make exoplayer
behave like it used to before multiple program support. Developers
who want to take advantage of the multiple program support are probably
less than the ones who only want their stream to "just work". This is
particularly useful for streams obtained after a filtering component,
like a tv tuner.

Issue:#2757

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

This imitates DashMediaSource's behavior.

Issue:#2623

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

This will allow supporting more encryption schemes. Including some
that require more encryption data, like the encryption pattern.

Issue:#1661
Issue:#1989
Issue:#2089

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

Dev v2

Remove fully-qualified name

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

This is most commonly caused by malformed media, where
the media indicates that something we need to make an
allocation for is *really huge*. Failing playback is
appropriate for this case; killing the process is not.

Issue: #2780

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

Added repeat mode toggle buttons to UI. Current mode gets forwarded to
Exoplayer instance, but without playback behaviour changes yet.
Translations for button descriptions are also missing - this will be another CL.

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

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

Based on https://github.com/waywardgeek/sonic/commit/7b441933.

Issue: #2774

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

The default byte order for ByteBuffers is big endian, but platform decoder
output buffers use native byte order. AudioProcessors handle native byte order
input/output.

When using a software audio decoding extension the Sonic audio processor would
receive big endian input but was outputting to a native byte order buffer,
which could be little endian. This mismatch caused audio output to be
distorted.

After this change both platform decoder and extension decoder output buffers
should be in native byte order.

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

If the codec isn't adaptive, there's no need to accommodate
the width/height/input-size of streams that don't have the
same resolution as the current stream. This is because we'll
always need to instantiate a new codec anyway.

Issue: #2607

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

Issue:#2743

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

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

Related to GitHub Issue #2577.

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

(Relating to GitHub Issue #2577)

All getter, setter and callbacks have been added and value of repeatMode is
passed to getNextXXXIndex methods.

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

Issue:#2773

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

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

A DummySurface is useful with MediaCodec on API levels 23+.
Rather than having to release a MediaCodec instance when the
app no longer has a real surface to output to, it's possible
to retain the MediaCodec, using MediaCodec.setOutputSurface
to target a DummySurface instance instead. When the app has
a real surface to output to again, it can call swap this
surface back in instantaneously. Without DummySurface a new
MediaCodec has to be instantiated at this point, and decoding
can only start from a key-frame in the media.

A future change may hook this up internally in MediaCodecRenderer
for supported use cases, although this looks a little awkward. If
this approach isn't viable, we can require applications wanting
this to set a DummySurface themselves. This isn't easy to do with
the way SimpleExoPlayerView.setPlayer works at the moment, however,
so some changes will be needed either way.

Issue: #677

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

Looper.myLooper(), the default looper, may be null in background threads. This adds a fallback to use the main app looper.

This will allow ExoPlayer instances to be built in background threads in Photos.

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

Add attributes for the scrubber handle color and unplayed color. If attributes
are missing, derive defaults from the played color.

Issue: #2740

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

When using the CronetEngine.Builder class, it automatically selects the
Cronet version preferring higher version codes and falling back to a Java
Http implementation if no native or GMSCore version is available.

This version selection has now been moved into the CronetEngineFactory
class to always prefer GMSCore over natively bundled versions. We also
ignore the Cronet internal Java implementation. Instead, users of
CronetDataSourceFactory can provide their own fallback factory. If none is
provided, we use DefaultHttpDataSourceFactory.

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

Using the new getNextWindowIndex method of Timeline, LoopingMediaSource now
uses a InfinitelyLoopingTimeline which does not unroll the windows to
157 million iterations but just starts from the beginning. If an explicit
number of iterations is given, we still unroll.

This change also allows multi-window timebars to show infinitely looping
playlists correctly.

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

The blaze BUILD file for the Cronet extension now has three options:
Using native bundled Cronet libs, using GMSCore, or using whichever is newer.
The GMSCore version is preselected (as it is the smallest), but other variants
may be used by uncommenting the respective lines.

The API is the same for all cases and the CronetEngine.Builder automatically
selects the newest option or falls back to default http.

To avoid that apps using this extension need to add a dependency to Cronet
themselves, I added a CronetEngineFactory to the Exoplayer extension.

Gradle builds can't be supported (as far as I can see), as the GMSCore Cronet
version is first party only.

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

(Preparation for Repeat Toggle Function - GitHub Issue #2577)

In addition, Timeline now also got a getPreviousWindowIndex and a
getNextPeriodIndex method with default implementations.

Changed ExoPlayerImplInternal and PlaybackControlView to use these
methods at all occurances of period and window index operations.

Note: Does not include repeat mode yet and no timelines are actually
using it so far. Please wait for the next CLs for this.

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

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

Improved Documentation

Added missing coma and fixed typo for EventListener#onTimelineChanged

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

To inject custom renderers into SimpleExoPlayer, developers
currently need to extend SimpleExoPlayer and override the
renderer building methods. This is in contrast to the rest
of the library, where we use proper injection. This change
restores consistency. I think it's fine to make
SimpleExoPlayer final again, but if we find people extending
it for non-renderer purposes, we can revert that part of the
change.

ExoPlayerFactory now has analogous methods for the simple
and non-simple cases, which is a nice outcome.

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