SDK / exoplayer

I've found myself doing this a couple of times during local
debugging. It's harmless to have it public, and seems pretty
useful for debugging inside of the mp4 package.

This is in preparation for adding support for AC-3 in HLS.

Also parse E-AC-3 boxes.

fix for issue #403

Seems a little hacky to define this in Track, but there doesn't seem to
be a particularly nice alternative.

Issue: #406

I was hoping not to avoid this, but in the case of a parsing
failure during preparation we keep retrying forever!

Using a file:// URL for loading an HLS stream (for testing) would fail due to
casting the connection to an HttpURLConnection in DefaultHttpDataSource.

This change makes UriDataSource an interface for objects that are DataSources
with URIs. That allows for reading manifests for HLS using just a UriDataSource
rather than an HttpDataSource (URLs in the playlist are relative to the data
source's URL so the getUri method is needed).

Github Issue: #363

On retrying loading a chunk, the state of the extractor was reset due to a call
to seek(). Prevent this call by only calling init() if no bytes were loaded.

Also make the DefaultExtractorInput use the loading position not the original
stream position so that its getPosition() method returns offsets relative to
the start of the stream, which fixes a bug where the chunk index offsets would
be relative to the wrong position if there was a retry while loading the chunk.

BaseChunkSampleSourceEventListener.onLoadCompleted.

Issue: #227
Issue: #389

1. Reset retry count to 0 if a Loadable makes progress.
2. Handle resume correctly in the case of live streams.

Issue: #227
Issue: #389

Vorbis decoder in android MediaCodec [1] expects the last 4 bytes of the sample to be the number of samples in the current page. This definition holds good only for Ogg and is irrelevant for WebM. So we always set this to -1 (the decoder will ignore this value if we set it to -1). The android platform media extractor [2] does the same.

This works around an issue the audio track continues to play audio data written
after calling AudioTrack.pause(), which breaks rebuffering behavior (as video
can never catch up if audio continues to be consumed, in some circumstances).

Also don't increment the timestamp wrap count if the track is paused, to work
around an issue where the playback head position jumps back to zero after the
AudioTrack position jumps back to zero.

Issue: #231
Issue: #227

ENCODING_PCM_8BIT support is not required.

AudioTrack.getMinBufferSize does not handle ENCODING_DEFAULT so
switch back to ENCODING_PCM_16BIT.

Issue: #339

The OMX component needs to be configured with a format that has a
MIME type of audio/raw. Remove Ac3PassthroughAudioTrackRenderer,
which is no longer used.

This prevents memory leakage even in the case where the app
is still holding a reference (direct or indirect) to the
Allocator.

Issue: #275