SDK / exoplayer

Issue: #731

The following sequence was problematic:

1. See start of a cluster having not output a seek map. Decide
   to seek for the cues. Enter CUES_STATE_BUILDING state.
2. Error occurs before seek map is output.
3. ExtractorSampleSource isn't prepared yet, so restarts from the
   start of the stream.
4. See start of the same cluster having not output a seek map.
   This time cuesState is CUES_STATE_BUILDING, so we just carry
   on. We then fill the buffer with sample data, despite the
   source not being prepared, at which point we get stuck.

It's unclear to me why cuesState needed three states, so I've rm'd
the BUILDING state. Step (4) above will now do the same thing as
in step (1). If the failure repeats, we'll eventually fail, which
is WAI.

Issue: #514

Second time lucky. We should just move to the next subtitle
when it's started. Simples.

Also do some significant cleanup to the extractor.

These MP3s are unseekable but allow calculating the VBR duration correctly.

Treat streams as live only if they are unseekable and lack a duration.

Issue: #713

Fixed issue where calling valueAt on a SparseArray with an index greater than the size of the SparseArray would sometimes return the class' internal DELETED object and cause a ClassCastException.

- Remove unused method in DashChunkSource.
- Remove inputEncoding parameter for subtitle parsers. We're
  ignoring it in all but one of the parsers, and for the one
  that does use it, it'll only ever receive null, since that's
  all we're passing.
- Make TextTrackRenderer advance to the next subtitle even if
  the current one hasn't finished, in the case that they overlap.
  This shouldn't ever really happen, but it seems best to trust
  the start time of the new sample rather than the last event
  time of the previous one.

May as well. Also specifically fixes showing the language
for subtitle tracks that have application/* mime types.

I'm assuming this will be fixed in API level 24.

- Video track is always marked as adaptive, the resolution is
  stripped out (since it's otherwise just set to whatever the
  resolution of the first selected variant is), and the max
  dimensions are set.

Issue #514

Limitation: Successive periods must expose the same adaptation
sets and representations.

GitHub Issue: #557

Enable override of open/close in StreamingDrmSessionManager

Make it so that extensions of StreamingDrmSessionManager may override open/close.

Issue: #690

Issue: #690

Issue: #514

This is needed for several use cases:

- ExtractorSampleSource with option to play both embedded and out-of-band
  subtitles.
- HLS multi-audio and out-of-band-webvtt.

- Migrate demo app to use new APIs.
- Add multi-track support for ExtractorSampleSource case.
- Add multi-track support for SmoothStreaming use case.

The final step is to add support back for the DASH use case and
delete MultiTrackChunkSource. This is blocked on multi-period support
landing, in order to prevent a horrendous merge conflict. We also
need to update HLS to expose sensible track information.

Issue: #514

Fixed bug of AES URI Pattern for hls

Issue: #689

When ChunkSource implementations implement multi-track for DASH and SS,
format selection will move inside of ChunkSource. If we, for example, fail
to query the decoder to determine which tracks are playable, we need an
opportunity to fail (i.e. say we're not prepared, so that maybeThrowError
is called, from which we can throw).

This may go away in the future if we remove the distinct preparation step
and treat tracks/formats as things that can change dynamically, but for now
this is what we have.

Issue #514.

Fix reading the first slice flag, which before could cause a read out of bounds
if the NAL unit started at the end of the buffer.

Handle non-VCL NAL units by flushing a pending sample when starting to read one.

Issue: 713

Also:
- Better document MediaFormat.
- Document getFormat to indicate what it's good (and not good) for.

multi-track support upstream to the ChunkSource interface.

This change does not yet make use of the newly exposed APIs. This
will come in a subsequent CL.

Issue #514.

- Currently all subtitles we parse contain timestamps relative to the sample
  timestamp, however we add the sample timestamp in inconsistent ways (sometimes
  in the Subtitle, sometimes in the SubtitleParser). This change converges on
  a single approach. It also paves the way for passing absolute offsets to use
  instead, and being able to apply them in a consistent way in a single place
  (PlayableSubtitle). This functionality will be required for ISO 14496-30 TTML
  embedded subtitles.

Issue: #689