SDK / exoplayer

I think such manifests are invalid, and I haven't seen any examples,
but given it's trivial to fill in the duration if the periods define
durations, it seems worth being robust.

- It's not possible to determine a period's duration just from the
corresponding Period element in a DASH manifest. It's necessary
to look at the start time of the next period (or the duration of the
manifest for the last period) to determine how long a period is. We
don't currently do this in the parser, and hence set duration incorrectly.
We also set period start times incorrectly because we don't set it to
equal to sum of the durations of prior periods in the case where it's
not explicitly defined.

- We're currently propagating these (incorrect) values all over the place
through data-structures that we build when parsing the Period element.

- This CL removes this redundancy, storing only the start time of each
period in Period elements, and not propagating it elsewhere. It's then
used when required in DashChunkSource.

The main change here is to add PeriodHolder.updatePeriod, which is
analogous to RepresentationHolder.updateRepresentation.

Fixed potential issue in which a live-edge latency greater than the duration of the manifest would result in the latest available time being lower than the earliest available time.

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.