SDK / exoplayer

Without this, the byte is cast as follows (in bits) if the top
byte is set:

10000010 -> 1000000000000000000000000000010

This works because we then always shift at least one bit left,
and only look at the bottom 8 bits of the result. It's confusing
though. It's clearer if the cast to int gives just adds zeros to
the front, like:

10000010 -> 0000000000000000000000010000010

Fix a signed right shift issue in BitArray.readUnsignedByte()

Make BitArray.readUnsignedByte() a bit more clear by using int value instead of byte to prevent unnecessary convert from int to byte.

Fix an issue in BitArray.readUnsignedByte() returns incorrect value when bitOffset is not zero and data[byteOffset + 1] starts with bit 1.
This is caused by signed right shift, the fix is simply to make it unsigned right shift.

dev -> dev-hls

FrameworkSampleSource with FileDescriptor

Move Closed Captions processing to Eia608TrackRenderer. Use TextRenderer interface for captions. Sort captions based on video frames DTS. Add better control characters and special characters in basic North American character set support. Fixes #156

dev -> dev-hls

Issue: #217
Issue: #228

Empirical testing in shows increased robustness.

- Workaround issue where video may freeze whilst audio continues
  on some devices that have entered bad states.
- Fix wrap-around for playbacks lasting more than 27 hours.

Apparently some servers don't like it, and in general it's
unnecessary to set the header for this case.

Refine logic for determining AudioTrack size.

- Target 4x the minimum specified by the framework.
- Impose a minimum duration (250ms).
- Impose a maximum duration (750ms, or the minimum
  specified by the framework if that's larger).

I've removed the ability to specify the multiplication
factor, since the underlying implementation is getting more
complicated, and we should really be able to figure this out
internally.

dev -> dev-hls

log all AudioTrack errors

Include gradle plugin 1.0.0

Include gradle plugin 1.0.0

Include gradle plugin 1.0.0

dev -> dev-hls

Issue: #214

Previously samples belonging to disabled tracks would just
accumulate in an arbitrarily long queue in TsExtractor. We
need to actively throw samples away from disabled tracks up
to the current playback position, so as to prevent this.

Issue: #174

I'm not sure exactly what the implications of this change are,
but I'd really hope that only one program in each stream is carrying
audio/video. For GoPro cameras, they expose the video stream in
the second program, for some reason.

Issue: #116

We've seen a few streams where this assertion fails. If you
just skip the packet, things appear to recover correctly in
all cases I've seen, so replacing failure with a warning.