SDK / exoplayer

- Call onDisabled last. onDisabled really shouldn't be doing
  anything with the stream, so pretty sure this is fine (and
  guarantees the stream is cleared properly even if onDisabled
  throws a RTE).
- Remove super.onDisabled calls from Text/Metadata renderers.
  This is just for consistency; we don't make such calls in
  other direct descendants of BaseRenderer.

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

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

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

the current size.

https://github.com/google/ExoPlayer/issues/2782

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

Issue: #2788

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

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

-------------
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

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

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

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

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

When using a multi window time bar, the onScrubStop method uses another
method to estimate the seek position than the updateProgress method for
rendering the time bar. If the time line contains windows starting with an
ad period followed by other content, they differ in their behaviour.
 - updateProgress checks all periods and leaves out all ad periods
 - onScrubStop only checks windows and leaves them out when the first
   period is an ad.

Changed onScrubStop to fit approach in updateProgess.

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

Without this, newer android NDKs (r14+) fail to compile.

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

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

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

Disable libjpeg dependency when building libyuv.

Partially fixes Github Issue #2661

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

Fixes the following issues:

1. When a surface is set, it's expected that the renderer will
notify video size + when a frame is rendered to it. This is true
even if the surface isn't changing. Right now this is achieved
by setting renderedFirstFrame to false, but this is problematic
in the case that the surface isn't changing because (a) it will
force rendering of a subsequent frame to the output even when
paused, which is incorrect, and (b) isReady will return false
until this occurs.

2. When the surface really is changing, isReady can return false
until the first frame has been rendered into the new surface, which
will break seamless surface switching. This change allows isReady
to return true up to allowedJoiningTimeMs for this case.

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

* colorSpace, colorRange and colorTransfer are relevant to all videos.
* The rest of the fields are relevant only to HDR videos.
* Tested on a prototype device that decodes VP9 profile 2, 10 bit.
* The Webm spec spells color as 'colour' so the webm id reference use the same spelling.

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

This prevents illegal casts.

Issue:#2702

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

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

Prior to this change, the only way to switch SimpleExoPlayerView
was to do:

oldView.setPlayer(null);
newView.setPlayer(player);

This would cause the video renderer to have to transition through
oldSurface->noSurface->newSurface, which is inefficient (noSurface
requires platform decoders to be fully released).

After this change we support:

newView.setPlayer(player);
oldView.setPlayer(null);

This results in direct oldSurface->newSurface transitions, which are
seamless on Android M and above. The change also adds some robustness
against developers ending up with strange behavior as a result of
clearing the player from a view in a different ordering than we expect
w.r.t. registering of other listeners.

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