SDK / exoplayer

Merge dev -> dev-l

The key change here is that nextLoadPositionUs is set to -1
if we're not loading but don't have a next chunk ready to
load. This ensures that "missing chunks" in one stream don't
prevent chunks in another stream from loading. This occurs
in SmoothStreaming with TTML subtitles, where the chunks are
sparse.

Propagate elapsedRealtimeUs to the video renderer. This allows
the renderer to calculate and adjust for the elapsed time since
the start of the current rendering loop. Typically this is <2ms,
but there situations where it can go higher (normally when the
video renderer ends up processing more than 1 output buffer in
a single loop).

Also made variable naming more consistent throughout the package.

So that we actually catch it, rather than having the process crash!

Add file missing from "Improve subtitle handling" change.

Update dev-l

- Move parsing onto a background thread. This is analogous
  to how frame decoding is pushed to MediaCodec, and should
  prevent possible jank when new subtitle samples are parsed.
  This is more important for out-of-band subtitles, which can
  take a second or two to parse fully.

- Add Useful DataSpec method.

- Use native frame release timing in video renderer for
  smoother video playback.
- Avoid unnecessary memory copy steps in audio renderer.
- Use non-blocking AudioTrack API.

Issue: #12

Previously we'd end up blocking forever in this case, which
is the worst thing we could do :). We could either throw an
exception or just print a warning. Printing a warning is more
in line with what other methods do (Handler prints a "sending
message to dead thread" warning).

This allows ManifestFetcher to both execute the initial
manifest load and be plugged into an ExoPlayer ChunkSource,
where it can be used for repeated manfiest refreshes during
live playback.

Use locally bound variable instead of class variable.

Do this even if stop/disable fails.

Ignore the path of the base Uri if the reference starts with "/".
Spec - http://tools.ietf.org/html/rfc3986#section-5.2.2

This API wasn't particularly nice. Best to remove it whilst
hopefully no-one is using it. Leaving the ReadHead abstraction
in place, since it might well prove useful in the future.