SDK / exoplayer

The sample data position is the sum of the data offset and the base data offset.
The base data offset is either specified in the stream, or defaults to the first
byte position in the moof box. (We only support one traf per moof currently, so
the offset does not need to be assigned for later track fragments.) The data
position can optionally be offset by a data position read from the trun.

The auxiliary information offset is calculated in the same way, but using an
offset read from the saio box.

Issue: #837
Issue: #861

- Added TtmlColorParser to workaround JellyBean issues with named colors.
- Support rgb and rgba expressions as well.

Context:
- Currently, playback is significantly more juddery with it disabled,
  particularly on AndroidTV.
- We should be able to do the "best" job of this internally, so injection
  doesn't buy anything useful. If someone has a better implementation for
  adjusting the frame release, they should improve the core library.

The only Samsung devices with names starting "d2" that we're aware of
are Galaxy S3 variants, and also one Samsung Galaxy Pocket Neo d2aio
SAMSUNG-SGH-I747Z. This change speculatively includes that device too because
its name is very similar to SAMSUNG-SGH-I747 which is known to be affected.

Issue: #548

Issue #838

Documentation: https://developer.sony.com/develop/tvs/android-tv/design-guide/

On API 23 we should also check Display.Mode (where supported).

Issue: #800

Issue: #800

NVIDIA Shield before API 23 supports DTS passthrough, so this change inlines the
constant value.

Try re-sync'ing to the next level 1 element when invalid data is found. This
corrects the behavior for test case 4 in the mkv test suite.

Partially Fixes Issue #631

This makes it possible to exit the player when using e.g. an Android TV with a
keyboard.

For example:
adb shell am start -a com.google.android.exoplayer.demo.action.VIEW -d http://...

As per the end of the related issue, it's likely that all devices
running the affected API levels + decoder are affected by the same
issue.

Issue #464

Add support for TrueHD audio codec in WebMExtractor

Add support for MPEG2 video codec in WebMExtractor

Make MediaCodecUtil.getMediaCodecInfo public

1. Change package name (rm "datasource")
2. Require injection of OkHttpClient through all constructors, and
   remove allowCrossProtocolRedirect/connectTimeout/readTimeout
   constructor arguments. The client should be configured with these
   prior to injection.
3. Fix code style to be consistent with the project.
4. Simplify call to get contentLength. I'm pretty sure okhttp returns
   the correct value when gzip is enabled, so there's no need to check
   this in the data source.
5. Misc cleanups.

Add an extension that provide DataSource using OkHttp

This change keeps the proportion offset * 256 as a floating point value rather
than rounding it before linear interpolation, which will increase precision
slightly when seeking in streams with XING headers.

In practice, this won't make much of a difference because precise seeking in VBR
MP3s with XING headers seems not to be possible without reading the entire file,
due to the fact that the (uneven) distribution of bits is represented by a fixed
number of table of contents entries.

Issue: #825

- The old approach was technically incorrect, because the checks
were "capacity < sampleSize" and hence neglected the fact that
the buffer position may be greater than 0 (e.g. if the caller
wants to prefix the sample with some additional data).

- Also proactively throw an exception if the buffer is too small,
rather than wait for the failure when we actually do the write.

This works around an issue where some devices, such as the Acer Iconia,
don't allocate large enough input buffers for H264.

Issue: #616
Issue: #714