SDK / exoplayer

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

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

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

I'm not really sure how best to document this in TrackRenderer;
it's a bit of a weird feature. For now, I've gone with the vague
approach.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112150939

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

See the documentation of buildTracks for the gory details.

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

This CL exposes the cue settings parser in order to allow its usage from the MP4Webvtt extractor. Also fixes a few mistakes from the previous related CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=112145806

* AudioTagPayloadReader was strangely parsing an audioSpecificConfig
  itself, using the parsed values to build a new audioSpecificConfig,
  then passing the newly constructed instance to be parsed by
  CodecSpecificDataUtil. Unfortunately the translation was lossy ;).
* Treat Duration=0 as an unknown duration.

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

- I think \r and \n are handled the wrong way around?
- We only expect to encounter a BOM sequence at the start of a
  file, but it feels fine to automatically discard it in all
  cases for simplicity. A BOM sequence doesn't mean anything in
  UTF-8. See https://en.wikipedia.org/wiki/Byte_order_mark. Note
  that I think the advice not to remove it on that page relates
  only to the case where the file is being edited + saved.

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

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

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

There are multiple issues with HlsSampleSource's use of
LoadControl that become apparent when you attempt to use
the same LoadControl for loads by another source.

* In the "limbo" state HlsSampleSource doesn't start any
  new loads, but doesn't update the LoadControl to tell
  it that it doesn't want to load anything either. This
  can prevent another source from starting the loads that
  it needs to make to complete preparation, causing
  playback to become stuck.
* The LoadControl isn't updated properly when the EOS is
  reached. This can cause playback to become stuck near
  the end of the media.
* If HlsSampleSource is released from being in the "limbo"
  state, it doesn't unregister itself with the control.

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

Given we need to do this in HlsPlaylistParser in the normal
case (i.e. not MEDIA_TAG), we may as well just be consistent
and do it everywhere.

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

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

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

Currently only supports a single offset to the full media timeline
(indicated by a duration of 0). This is most often used to fix the
non-zero starting presentation timestamp introduced when B-frames
are present.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=111816916

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