SDK / exoplayer

Fixes: #1176
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112781092

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

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

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

When a seek is performed, renderers currently perform the
actions that they need to take in two places: Some changes
are performed in seekTo implementations. Other changes are
performed when discontinuities are read from the source.

In HLS we need to perform what is effectively a seek
originating in the source. To support this, this CL allows
discontinuities read from the source to modify the playback
position. All actions that renderers perform as a result
of a seek are moved to be performed when a discontinuity is
received.

Best way to understand CL:
- Look at SampleSource interface change and then at the
  concrete implementations, to make sure they've been
  changed properly.
- Look at SampleSourceTrackRenderer change.
- Look at concrete renderers. The general pattern is that
  code previously performed in seekTo and READ_DISCONTINUITY
  is merged into onDiscontinuity().

Note: This will be further untangled in V2.

Issue #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112720746

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

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

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

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

Based on AOSP's MP3Extractor.cpp and ID3.cpp.

Issue: #497
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112685664

As part of this change, Extractor.sniff may read/skip (not just peek) if it
returns true. This allows Extractors to avoid parsing the input a second time in
read.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112683272

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

Also fix a couple of style nits.

Issue: #398
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112412961

This makes sense until we need to support seeking in the live window.

Issue: #676
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112402026

Also apply the workaround for the secure variant of OMX.SEC.avc.dec.
Note that it's not necessary to do the same for the RK decoder in
the method below, since that workaround is targeted at SDK_INT<=17
and secure decoders only came along in 18.

Issue: #603
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112395376

link track language attribute in Smoothstream parser

Also simplify the implementation slightly.

Also, use terminology from ATSC spec in Ac3Util comment.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112254908

After this change, AC-3 uses about 20 KB and DTS uses 49 KB.

For comparison, 'normal' PCM playbacks use by default (depending on the device
and input format) about 45 KB. For passthrough, the following buffer sizes were
used before this change:
- Nexus Player AC-3: 23 KB
- Nexus Player DTS: 25 KB
- NVIDIA Shield AC-3: 15 KB
- NVIDIA Shield DTS: 16 KB (caused underruns in some DTS-HD playbacks)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112254836

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

Using the provided methods by the previous refactors, it is now possible to use all of the WebVTT features already available.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112243172

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

The TTML 1 spec. defines an exact RGBA color tuple as #rrggbbaa
See https://www.w3.org/TR/ttml1/#style-value-color

Android's internal representation is ARGB.
The correct parsing therefore requires a bit of extra byte shuffling ...

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