SDK / exoplayer

Issue #765

Issue #763

Issue: #755

- Admit we don't know the mime type (using unknown mime types) rather
  than passing the container mime type.
- Pass the correct mime type for opus, vp9 and vp8, and remove the incorrect
  container checks in the corresponding extensions.

All valid Android devices should pass these tests.

- Fix building with APP_ABI=all by configuring for all architectures.
- Keep vpx_dsp which is required for building successfully.
- Use perl -pi -e not sed, for building on Macs.

Issue #753

- With this change, you can select from the individual video formats in
the demo app, as well as the regular "auto" (adaptive) track.
- DashRendererBuilder no longer needs to create MultiTrackChunkSource
instances for the multiple tracks to be exposed.

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.